Free 1-Hour Professional Skills Boot Camps for SDLC Professionals

written by: Admin on January 9th, 2015

Start 2015 off Strong with Free Professional Skills Training for SDLC Professionals

As an SDLC training company, we have the privilege of working very closely with a large number of SDLC professionals around the world. Constantly having our ear to the ground, we hear over and over how important it is to SDLC professional to maintain strong business and communications kills in order to thrive and maintain continued career growth.

The fulfillment of this need in 2015 has become a major priority for ASPE-SDLC. In response, we have developed a series of 1-hour boot camps that will be presented in the form of free webinars.  These boot camps will be focused, information packed, skills building sessions covering the most critical professional skills need for long term career growth.

Professional Skills Boot Camp Schedule:

Click to continue »


30% off Remaining January Seats

written by: Kaete Piccirilli on January 16th, 2015

Get prepared for projects and growth in 2015 with the ASPE-SDLC course offering.  We know that as the year progresses and projects start that it can be hard to find time to squeeze in that training you’ve wanted to get completed. That’s why we are offering one of our best discounts to fill the remaining seats that are available in our January in-person and live online training classes.

We’ve provided a list for you to browse of the classes with remaining seats available in January. Register now using the code JAN011530. You can register online or by giving us a call. Be sure to reference this code to receive your 30% off discount.


Web Seminar Recap: The 5 Levels of Agile Planning

written by: Jennifer Johnson on January 14th, 2015

When a software development professional first hears about Agile, they are often initially incredulous that this type of approach can work due to a misperception that Agile simply means “no planning.” This belief could not be further from the truth. Agile teams tend to plan more throughout the course of a project than a traditional approach, albeit in a different fashion than they may be accustomed to. Rather than planning once at the beginning of a project, Agile teams practice continuous planning throughout the project.

This web seminar explored the five Levels of Agile planning, and how they help teams ensure that teams are able to benefit from what they learn over the course of their development and delivery efforts.

Mark Arntz answered a few more of your questions after the seminar. Check out the remaining Q&A below:

Q1: What are the planning tools and key planning deliverables to clients in case we don’t use Microsoft project

A: There are many different tools available for Agile Project management, but the most important thing to remember is the tools should not drive the process. An Agile Manifesto value states: We value Individuals and Interactions over Processes and Tools. It’s a really good idea to figure out how we want to get the work done before going to an automated management tool. Of course, from the very start, we do want some kind of tool to help organize the work, but Agile at its simplest form leans on physical cards placed on taskboards on the wall. It is recommended that whenever possible this approach precede a more automated approach. When we have distributed teams, this may not be possible. Also, when we have a more mature Agile organization, we may have already settled this question and new teams tend to bypass the more physical / manual approach for managing the team. Some tools that are very popular, based on feedback from my classes and personal experience are:

Jira – a less expensive option
Rally – more expensive but more sophisticated
Mingle – more customizable to your approach
VersionOne – Much like Rally
TFS with Agile extensions – a Microsoft product – for Microsoft shops.
Key Planning Deliverables:

I’m going to try and answer this is in a paragraph, which is difficult. Planning deliverables should never be created in isolation from the customer. The Agile team has a role called the Product Owner. The Product Owner most ideally comes from the business side and owns the Product Vision and Product Roadmap – planning deliverables. The Release Plan is shared between the Product Owner and the Agile team. The Agile team owns the Iteration Plan and the Daily planning of the Daily Standup (Scrum). The requirements that eventually will fill up the Release Plan and then an Iteration Plan are called User Stories. These are owned by the Product Owner, but the development team contributes to their Progressive Elaboration (filling in the details Just-In-Time). Other deliverables are determined by the Agile team and belong to the Definition of Done – the things we do to complete a requirement. Another type planning deliverable not really prescribed but allowed for in the Agile approach is a compliance type Story. If the organization requires some document for internal use or regulation satisfaction, this can be created as a Story that resides on the requirements list called the Product Backlog. This Story will be done by the Agile team, when the Product Owner sets it as a priority.

Q2: Any special considerations while adopting agile to a Fixed Price contract?

A: From the Agile Manifesto: We value Customer Collaboration over Contract Negotiation. This does not infer that in Agile we don’t have contracts, it just instructs us that any contract type that tends to reduce or eliminate Customer Collaboration is not advised. The Agile Process addresses risk in a different way than by creating a Black Box contract that a vendor signs up for and if all aspects of the contract are met success is declared. Experience has shown that while a contract may be met, the customer may not be happy with the end results. Firm Fixed Price Contracts would be the least attractive contract approach for Agile work. Even with US Government work, options are available to avoid this approach and still meet objectives that protect the taxpayer investment. There is a document that the government has produced that can help with more ideas around this subject:

Contracting Guidance to Support Modular Development

Q3: any comments about doing an agile process with PCI (payment credit info) apps. Some say like CMMI that agile is not for this type of dev because of the governance

Agile is for anything that is complex (or in other words, learning is required – i.e. invention). Governance can be accommodated as customer/stakeholder specified value captured as a story and scheduled as work to be done by the development team. Some aspects of governance can also be built into the Definition of Done. An example of Definition of Done:

DoD: To complete any Story we do the following:

1) Design the solution
2) Create Acceptance Tests
3) Create Unit Tests
4) Build the Solution
5) Write User Documentation
6) Update the Release Notes
7) Do Code Review
8) Etc.

If there is a requirement to do a Security Review as part of completing any requirement, then just add it to the checklist of things we do, or the Definition of Done.

Q4: Is there a project management tool specifically developed for Agile or a tool shouldn’t use at all as it will become a admin burden

See Q1.

Q5: We have seen various level of planning the complete requirement/ roadmap/ vision. Do we break the design process accordingly? if yes, it might introduce risk with addition of each requirement where design might be changed

A: Requirements called stories that are implemented by the Agile team should align with the previously created Vision and Roadmap. They have been scheduled for implementation during Release Planning in a Release Plan. Before taking them into an Iteration the Agile team digs into the “requirement design” which is delayed until close to the time the Story is implemented. Usually one to two iterations ahead of implementing a requirement, developers and customers go into a room in front of a whiteboard and start discussing the details of the requirement. Whiteboard diagrams, screen mockups or wireframes, use cases and any other known methods can be used at this time to dig into the details of the upcoming Story. The bottom line is that in Agile we embrace change and therefore expect that things will absolutely change. That’s why we do Agile.

Q6: Mark, we had challenge in using Agile for ERP implementation particularly due to larger work packet which may not fit in 2 weeks cycles. What is your experince in such cases say SAP implementation?

A: I don’t have experience specific to SAP. My experience is with the Oracle ERP solution, but I assume that there is great similarity. I’m having a hard time imagining work that cannot be broken down smaller. I agree that it may take some practice if you have not thought about it before, but with practice a team can usually learn to think about it in a way that accommodates slicing it up. If there is no way to slice it up, then this becomes an impediment to doing Agile.

Q7: How do we estimate a Scrum project which is fixed price project where we do not have all product requirements upfront.

Driving Investment Decisions:

What is the defined project goal? (Vision / Project Charter)
If the goal is reached what would be the benefit? (Business Model supporting the Vision)
Spend Justification
• How much investment would be reasonable to achieve the return or to make the Business Model work?
• What is the expected payback period?
• Have you considered the time value of money and is the payback period acceptable?

Feature Based Validation:
• Create a backlog of stories / epics / features
• Estimate all features in Story Points (size the backlog)
o You will first need to calibrate your Story Point size
• Build a team (maybe hypothetical team) and determine the cost of the team
• Define a Definition of Done or Standard Work
o What’s included in each Story Point
• Estimate # of Story Points that team can do in an Iteration
o be realistic – on the pessimistic side
• Divide the # Story Points in the backlog by the Velocity to find the # of Iterations needed to complete the backlog.
o Velocity = # Story Points a team can address on average in an Iteration
• Multiply the number of Iterations by the cost per Iteration
• Does the cost associated to complete the backlog support the Business Case?

Schedule Based Execution:
• Break your features into Stories
• Prioritize your Stories
– must have, should have, could have
• Use the team that will do the work to estimate the work in Story points
• Determine a realistic estimate of how many Story Points this team can accomplish per Iteration.
– Consider the Definition of Done and the amount of Productivity (6 hours per day?)
• Using the cost of the team, determine how many Iteration can be accommodated by the business model to set the go-live date.
• Locate the place in the backlog where all money has been spent or the go-live date has been reached.
• Decide if all must have’s and enough should have or could have stories can be included to support the business case.
• Move forward with flexible scope and fixed cost and schedule.
• Track against expectations.

Q8: What team composition is required for a successful Agile environment? Please discuss skills, positions, and team size.

A: The recommended team size is 5 to 9. The 5 to 9 guideline is not set in stone and it does not include the Agile PM or Product Owner, in my opinion. The team is eventually made up of Specialized Generalists. In other words, we don’t limit the kind of work that any member of an Agile team can pick up, but each team member has some proclivity towards certain types of work based on the specialization that they bring to the team. The team works together to build quality working software. When building an Agile team, a manager will want to have some QA, Dev, BA, Tech writing expertise so that the team has the skills to accomplish the work. Over time, these team members will pick up things that aren’t in their specialty and will grow into this Specialized Generalist.

Q9: how do we track re-opens from QA(testing)? or bugs coming from QA – adding those will change the iteration planning we had initially right?

A: This question promotes the paradigm of separation between QA and Dev. This is the traditional view not the Agile view. Agile promotes the concept of “Build Quality In” instead of “Check Quality Out.” The Inspection idea is not the same. So, things are not done until everyone says they’re done as part of the process. If a tester find a deficiency, it’s not really a defect, its just something more that needs to be done before we declare the requirement done. There may or may not even be an artifact of deficiency to track. The tester sitting next to the developer in the same room, may simply point it out and the developer says a minute later, “That’s fixed.”

Q10: Don’t you think is there any need to add additional step in the Agile planning that takes care of Lessons learned with focus on strengths and areas for improvement occur after each sprint and are included in the next sprints or so..

A: Yes, this is part of the Agile process and is called the Retrospective. It is not part of product planning, it’s part of the process continuous improvement or Inspect and Adapt process.

Q11: how does an iteration delay affect the total planned schedule/cost?

A: Scope is adjusted to meet cost and schedule expectations. This can only happen if the scope has enough non-must have requirements in the initial scope used to budget. See Q7.

Q12: Are there any best practices for a test manager to manager multiple agile testing projects?

A: The truth is that there is no such thing as a Test Manager in the Agile team. That does not mean that in practice the role has gone away, but usually test resources are primarily assigned to teams. They secondarily are members of what might be called a Center of Competency called QA, or BA, or DEV, or PM. These represent vertical silos. Generally silos are bad, but if they are loose or weak silos, residing in a weak matrix organization, then they provide benefit of promoting the competency that they represent while making the project team dedicated and protected from interruption from the Silo.

Q13: Which agile planning tool is widely used?

A: See Q1

Q14: do you recommend any tools that is very good for tracking Agile plans – iterations etc?

A: See Q1

Q15: where Business analyst role fit in Agile planning?

A: Same as Q12 and Q9.

Q16: Which are the 2-3 key quality metrics in agile?

A: Agile uses visual management tools or Information Radiators to track progress of the work. A non-Agile example is the use of a thermometer used in a United Way campaign to grow towards the goal set for the campaign. The most commonly used are called Burn-up Charts, Burn-down Charts, and Taskboards. Other metrics that are tracked:

• Commit v. Complete – we committed to 20 Story Points in the Iteration and only achieved 18 Story Points – CvC rate is 99%.
• Escaped Defects: The number of defects that get out into the field that should have been found before release but were not. These indicate a process that is in some way deficient.
o # Escaped Defects per Story Point could be one way to measure this.
Q17: Do we call a Requirement as a Requirement in Waterfall model and a User Story in Agile?

A: Usually yes.

Q18: Can we have a brief discussion on backlog ?

A: The backlog is a prioritized Requirements List. It contains Stories. There are two types of stories: User Stories and non-User Stories. User Stories are needs statements that represent a functional requirement. Non-User Stories are things that are needed for the product to represent quality, but the User may not recognize the value. The Backlog is DEEP (Roman Pichler – Product Management with Scrum)

1) Detailed Appropriately
2) Estimated
3) Emergent (Progressive Elaboration)
4) Prioritized
Q19: Do you have any recommendations for implementing Agile in a PRINCE2 centric environment?

A: Sorry, I do not. I’ve never been exposed to PRINCE2. If this is a more Waterfall kind of SDLC, then milestones can be lined up with the Agile process and teams can include work in the backlog that help achieve the milestones. If Check Quality Out requirements are needed, then these can be after-the-fact and not really included in Agile, but used as an after process that will then feed new requirements into the Agile process if things are found.

Q20: I manage a process improvement program for a CMMI Level 3 company. The biggest complaint is that our process set requires too much planning and paperwork. They say, “we want to be more agile.” How do I explain that agile’s planning is just as rigorous?

A: Remember, Agile is Barely Sufficient. Not insufficient. But, if you are doing things that nobody will look at after it is created – that is a good indication that it is waste and should be eliminated from the process. The LEANEST process is represented in the sitcom Bewitched. Darin asks for something and Samantha twinkles her nose and voila – there it is. If we could twinkle our nose and have working software, wouldn’t we want to do that. The fact is that we don’t have any such magic. So we do the things that bring us working software, but don’t get carried away, imagining that every possible document actually represents something of value.


This web seminar occurred on Tuesday, January 13th, 2015. Missed it? Find the slides and recording here!


Web Seminar Recap: Kanban for Applications – Kanban for Operations

written by: Jennifer Johnson on January 14th, 2015

Kanban systems have emerged as a fantastic and easy-to-use agile tool for tracking and managing workflow. But something interesting is happening – even as application teams have embraced Kanban systems as part of going agile, on the other side of the IT department operations managers and system administrators have begun using Kanban as a DevOps tool. Originally developed as a management tool for manufacturing, the analogy of using factory workflow to create products efficiently is proving full of lessons for all layers of IT – from projects and applications to deployment and ongoing operations.

Continuous integration expert Bryon Brewer, discusses the different areas of the development and delivery life cycle in which Kanban can be leveraged. On the operational/production side, Bryon helps you understand how to level out workflow, reduce operational Work in Progress (WIP), and uses kanbans to track, visualize, and optimize flow of work. On the application side, he discusses how an agile shop uses Kanban to help prioritize, estimate, and keep track of features, as well as of the build in general.

This web seminar occurred Friday, January 9th 2015. Missed it? Find the slides and recording here!


Trust or Narcissism?

written by: David Mantica on January 12th, 2015

As worker autonomy and empowerment become the topics of the day in business, the concept of trust is getting its day in the sun.

trustTrust in business is a relatively under-researched topic and something that is difficult to put objective qualifiers and measures on.  At the same time there is NO doubt that the lack of it (trust) or the weakness of it (trust) has a major impact on success in business today.  The problem in all of this revolves around the judgments that are made that go into trust.

Look at it from this perspective: in most cases trust is discussed in terms of an employees’ trust of the manager or company that employs them.  It (trust) is, therefore, dependent on the rationality of judgment each employee makes.  And from what I have read on this subject, in most cases, people just go ahead and assume that employee judgment is always rational. I can tell you from personal business experience (as both an individual contributor and a leader) that is NOT a correct assumption.

In economics you start by assuming the rationality of individuals, and economists do this when they hold everything else equal (ceteris paribus) in their analysis. Because the assumption in economics for rational activity is that people are doing whatever they need to do to maximize their utility, with utility being defined as satisfaction/gratification.

If you think about it based on the above you can see how “messed up” the assumption of rational judgment in business becomes. A business can’t function if all the actors are driving towards their own personal satisfaction or gratification. In “old school” management control through a dictatorial/command and control style of leadership (which is still in use today) was used to prevent this.  In this style, the team falls into line because they are not empowered to do anything else.  If you fall out of line you no longer have a job, so there was no real need for trust. Although if you had it, you most likely got higher productivity out of the team.

Click to continue »


How a Context Diagram Could Have Saved Big $$$

written by: Mary Repetto on December 16th, 2014


What is a context diagram?  Well, it is the coolest tool in the toolkit and it can save you from making some big mistakes if you use it in the beginning of your projects. It starts with a big circle that represents the scope of your project/system. Then we draw little boxes outside that big circle that show the people or things that interact with that system. We draw arrows from the boxes to the circle showing data that comes in and data that flows out. So, what’s the big deal? Well, when I worked for a big corporation we implemented a system and spent major dollars only to find out that it really couldn’t talk with some of our legacy systems. Bummer, the monies were already spent, so now what? Had we drawn this simple little diagram, we would have discovered right up front what interfaces we would need to ensure. Amazing how not doing your proper prep and using some key tools can make a difference….we lost hundreds of thousands on that one!


Do I Really Need to Model This Process?

written by: Mary Repetto on December 15th, 2014

It’s easy to get lazy and not feel like drawing things out, creating process maps or creating other diagrams.  However, think about what the real role of a business analyst is…to act as a liaison between the business and IT, which means we need excellent communications skills.  And, what better way to communicate than through visuals?!  As YOUR stakeholder, the business, I can read pages of tedious documentation or I can walk, with you, through a process flow where you describe to me not only “what is” but also “what will be”.  I can pick out the flaws with you, make suggestions, ask questions… with the end result being a collaborative solution to the business problem.  You now have my attention, understanding and complete support.  What could be better?