 | |
| Agile Approach and How to charter an agile project |
We all need some help sometimes when introducing agile methods into a traditional organization or working with a PMO entrenched in approaches inspired by A Guide to the Project Management Body of Knowledge (PMBOK Guide). Fortunately, a new guide to ease the transition is available, from the Project Management Institute of all people. The recently published Software Extension to the PMBOK Guide Fifth Edition acts as a Rosetta Stone for mapping and replacing traditional approaches with their agile alternatives.
The Software Extension to the PMBOK Guide was published in October of 2013 and is a joint development between IEEE (the Institute of Electrical and Electronics Engineers) and PMI. Based on the latest PMBOK Guide—Fifth Edition, it explains what project managers and project teams may want to do differently compared to the plain, vanilla advice of PMBOK Guide to be successful on software projects. Following the lead of some of the other extensions to the Guide, such as the extension for construction management, it explains the unique challenges for the industry and provides outlines for accepted good practices.
Download Also:
Being able to reference a guide developed and supported by two well respected bodies like IEEE and PMI adds confidence to the recommendations. It should remove some of the agenda-pushing suspicions that arise when a single group promotes a solution. The Software Extension is not an agile-only focused document though; it covers the spectrum from highly predictive lifecycles to highly adaptive ones:
Agile methods inhabit the middle to right-hand side of the spectrum; traditional software methods on the left to middle side. What the extension is clear to communicate--regardless of the lifecycle adopted--are some of the unique factors about software development that impact project management and this include:
- The intangible nature of software – Software cannot be touched and is difficult to reference. Unlike a door that you can point to and say “I want one of these, 7-feet high and 3-feet wide”, software requires more description to articulate clearly the required characteristics.
- We rarely create the same systems twice – Unlike some forms of construction, software projects are usually novel and unique. Lessons learned can be applied at an abstract level but the details and issues of one project are not directly applicable to the next.
- Requirements often change – Because software solutions are intangible, novel and difficult to explain, people can rarely gather an unchanging set of comprehensive requirements up front. Instead, some details emerge later and usage often uncovers missing/additional requirements.
- Non-linear scaling of resources – Since software design and development is largely a collaborative problem-solving exercise, adding more resources does not reduce effort in a linear way as adding more workers to a ditch-digging project might. Complexity and communication channels factor into the efficiency gained from additional resources Non-linear completion – Unprecedented, creative and research & development-type work rarely follows linear progression patterns. Using metrics from painting two sides of a square room, it should be possible to accurately predict the completion time for the remaining two walls. When designing a new video game or building a reservoir simulator, early progress may be less useful to predicting future progress due to the uncertain type of work ahead, complexity and uncertainty.
- Changing platforms and technologies – Many software projects employ new tools in an ever-evolving environment of platforms and tools. Interactions and incompatibilities between changing systems provide additional risks in these dynamic environments. Construction managers can understand the interactions between their basic commodities. Software project mangers work more in an environment akin to “steel 2.4 no longer being compatible to concrete 3.6”; the rapidly changing technologies create additional risks and complexity.
Once these realities of software projects are understood, the recommendations for a more exploratory and iterative approach to project execution and planning make sense. It is not due to a reckless abandonment of planning that agile projects recommend early proof of concepts and getting software into the hands of customers early. It is instead an acknowledgement that software is notoriously difficult to specify well up front, and a viable alternative to big-upfront design is incremental elaboration based on short build/feedback cycles.
In addition, prototypes and early technology studies using target technology are a prudent and risk-aware mechanism for verifying designs or uncovering issues early in the processes while there is still time and resources available to try alternative approaches.
The Software Extension to the PMBOK Guide walks the reader through each of the chapters of the PMBOK Guide, calling out processes that are generally executed in the same way on a software project and those that are often undertaken differently. Wherever a different approach is identified, the reason for the change is explained and one or more alternative techniques offered to meet the same high-level objective. The guide does not dismiss or discount the original goal, but instead offers some alternative tools organizations typically use when faced with the complexity and uncertainty of a software project.
The guide can be used to disarm the “agile vs. traditional” debate when discussing project process. Instead of people taking sides, the spectrum of predictive to adaptive process tools can be discussed and the appropriate set selected. Using a third-party guide sponsored by PMI allays the fears of the traditionalists, and having it co-written by agile proponents ensures agile methods are fairly represented, too. This does not guarantee consensus--far from it. But it can help provide a framework for productive discussion and debate.
Keys to Chartering an Agile Project
When you’re a project manager for a traditional project, it’s easy to write a project charter. You can sit in your office and write it alone, if necessary. You don’t have to involve the team. On an agile project, is that the right thing to do? Should you even use the same template? Agile projects are collaborative. You might not have an agile project manager for your team. You might have a ScrumMaster or a coach, neither of whom is a project manager. You might not have anyone who fills exactly the same role the project manager used to fill. But you still need a charter--it helps the team see the vision and the release criteria, among other potential other valuable information. How do you charter an agile project?
Do you know where you’re headed?
The first question I ask teams is this: Do you know where this project is headed? I don’t want to know about this iteration. The team might have an iteration goal. I want to know if they have a vision for the entire project. If you are transitioning to agile, you might have a project that has to fix some technical debt and a number of defects. Do you want to call that vision “Fix the debt project”? I don’t think so. It’s true, but it doesn’t “wow” anyone. It doesn’t explain why you are doing the project and why anyone should care about doing the project. Instead, a vision such as, “Technical debt payoff to make everyone’s lives easier by 10 hours a week” does have a wow factor.
If you add a dollar figure (the number you calculate from time spent waiting for broken builds and cost to fix a defect), you create excitement and energy for this project. That’s the difference between a yawn and a compelling vision. The vision has to last for at least one release of the software. If you are lucky, it will last for more than one release…but that depends on your project.
How do you write a compelling vision?
You write down everything you know about where the project is headed. Now, think about the people who will use the product. You don’t have to create personas, although that might be helpful. When you change the focus from you, the company or the product developers to the buyers/consumers of the product, you change your perspective. In this case, the future customers, future product development teams and the organization all win from completing this project. The future customers win because they will be able to obtain products earlier, the product teams won’t pull their hair out and the organization won’t be paying for waste.
That perspective allows you to create a compelling vision for the product. Brainstorm to generate enough words or sentences that you have a rough draft of a vision. Finally, edit. When I do this with teams, it takes us about 20-30 minutes to generate a vision. I suggest time-boxing this activity to 30 minutes. If you don’t have a finished vision in 30 minutes, it’s okay. Leave what you do have up on the wall. Return to this activity another day, and let this one percolate in the team’s mind for a while.
How do you know when you’re done?
Every project team needs to know when the project is done. You might say the project is done when there is no more value in the product backlog. However, if you have release criteria for the project, you might achieve project done-ness earlier than you imagine. Release criteria are the vital few criteria by which we will judge the done-ness of the project. I try to make them a balanced scorecard. If they are only about quality, the testers will own them. If they are only about date, the managers will own them. If they are only about features, the developers will own them.
Maybe your only criterion is a date. “We will release this product on September 23, 2013.” If that is your criterion, fine. Startups and products in an early market often have criteria like that. That’s because they need to make money and the date is critical. If you have SaaS (Software as a Service), you might have a daily release schedule or something even more frequent. In that case, you might have other criteria, or team norms such as:
- Our main trunk is always releasable.
- We eradicate defects as we discover them.
Teams use the vision and release criteria to make tradeoffs as they proceed throughout the project. The vision and release criteria alter decision-making. You might need more for a charter. The vision and release criteria are the minimum necessary for a charter. I like assessing the release criteria each iteration to see if we are done. Sometimes, the product owner likes to add more features and grow the project past the criteria. (I know, that never happens to you!)
What do the sponsors want from this project?
One of the things I like to add in a charter is the decision table about what the sponsors want. I don’t know about you, but I often work with project sponsors who want it all: a project that takes no time, has no budget, delivers a gazillion features, with no people. Sound familiar? If so, you might like the project pyramid and the project driver matrix. I use a project pyramid to help my sponsors walk around the project constraints and help rank the project driver matrix.
I explain that often, the organization thinks they have fixed the people, cost and desired date. However, agile provides us an opportunity to change scope often, because we finish features. And if we use the technical practices (part of the environment), we will have fewer defects. It is up to them what drives the project. The project sponsor needs to answer these questions; if it’s the end of the project, what do you want first:
- To finish all the features?
- To fix all the defects?
- Or to ship the darn thing?
PROJECT DRIVER MATRIX (FROM MANAGE IT! YOUR GUIDE TO MODERN, PRAGMATIC PROJECT MANAGEMENT)
Project Priority
Rank Release date
Feature set
Low defects
Cost to release
People and their capabilities
Work environment
Now you know what the first priority is and how you will make tradeoffs when it comes to risks. This will help the team and the product owner make decisions.
Who asks the questions? If you don’t have an agile project manager, who will ask these questions? This is an impediment the team needs to address and resolve. Some of you can ask the product owner, who will have the answers. Some of you will need to appoint someone to ask the sponsor. And, some of you will have to play rock-paper-scissors or pull straws to decide who asks the sponsor…but you need to ask the sponsor.
Chartering helps the project start and end If you’ve never chartered a project, consider it. Even if you have a project partly underway, consider it now so you know when to end. Charter the project with the team. Sure, use the same template. Make sure you include the vision and the release criteria, because agile projects start and end just as more traditional projects do. Every project needs a charter. Use a charter to start and end on track.
Use Cases or User Stories: Where Should Agile Teams Start?
One of the more contentious debates that seems to never be resolved is of keen interest to all agile practitioners: Should an agile team begin with requirements documented as use cases or user stories? Proponents from both sides of the debate make good arguments for their individual positions, leading to confusion for many who are just getting started with agile practices.
The Fundamental Problem Some practitioners say that use cases are necessary for their project’s success, while others state that use cases are inefficient--a waste of time--and that user stories are a better way to document project requirements. The reason this debate continues on over the years is that they are both right. Every project is unique. Certainly, projects can be grouped based on factors such as complexity, size, risk, industry and solution type; however, neither of these affects the use case versus user story decision. There must be some factor other than project characteristics driving the debate.
Use Cases
For those who are not familiar with the use case concept, here’s a quick overview. A use case is a way of documenting a business transaction or a process flow. It details the process steps, the people and systems involved in each step, the related business rules and the manner in which exceptions to the business rules are handled. A use case also establishes pre-conditions and results of the process flow.
Many different ways of documenting use cases have emerged since they were first described in the mid-1980s, but one common criticism is that many use case guidelines often lead to long, detailed documents. Agile critics of the use case format stress that preparing this level of detailed requirements documentation early in the project is very inefficient, as the high levels of change that characterize most agile projects leads to time wasted documenting detailed requirements that may eventually change or be removed from the project.
Frequent requirements changes in these agile projects means that team members will have to spend additional time keeping use cases up to date to reflect the impact of the changes, taking time away from other activities that may more directly contribute to making progress.
For some projects, preparing detailed use cases early on is clearly an inefficient process.
User Stories
User stories, on the other hand, are a completely different method of documenting requirements. This technique formed part of the core practices of the agile method Extreme Programming (XP), which was created in the 1990s.
There are several approaches to documenting user stories, all of which are characterized by simple, short statements describing a feature or deliverable required by a role (person or system). Some extend this to include the rationale or business benefit that justifies the requirement. User stories can be most simply defined as a very simple way of describing a business requirement in plain language, using a simple sentence or two. The details required to fulfill the requirement described in a user story emerge later in the project, just as the project team prepares to create the required feature or deliverable.
Agile proponents stress that on high-change projects, starting with only a list of user stories avoids preparing detailed documentation of requirements that are going to change (or be canceled) later, thus avoiding inefficiencies. In contrast to this, proponents of use cases argue that user stories do not provide the contextual framework to understand an entire process flow around the requirement, which could lead to misunderstandings and incorrect assumptions by the project team.
Resolving the Issue
As I mentioned earlier in this article, I believe that both groups are correct. Sometimes use cases are the right approach to documenting a project’s requirements, while at other times user stories are the best approach. The factor that needs to be considered when making the decision is the level of knowledge or contextual experience already possessed by the project team.
In projects where contextual knowledge is already present--such as when an internal project team is making changes to an existing product or service the team is already supporting--teams can start directly with user stories. Since they already have an understanding of the overall process and where these changes fit into that process, detailed documentation of that context is not necessary. These teams can begin directly with documenting the changes using user stories.
In other projects where teams are working on something brand new with no existing contextual understanding--such as when developing a new product or service for a new customer--teams do not have enough understanding of the business context for the project, such as affiliated processes and how exceptions are to be identified and handled. With the lack of contextual understanding, documenting requirements via use cases provides needed background details.
But what about the inefficiency of preparing detailed documentation up front? These teams should start with only high-level use cases to avoid wasted effort documenting details that will change later. In this case, the details are captured over time as the use cases are implemented, resulting in a complete, detailed set of use cases by the end of the project, capturing the “as-built” solution.
So the debate need not carry on about the need for use cases or user stories on agile projects. I believe that both are necessary, but should be used in different situations. Project teams need to keep in mind their existing contextual understanding and use that as a factor in making the right decision for a specific project.
Related Topics:
The Author: Ala'a Elbeheri
About:
A versatile and highly accomplished senior certified IT risk management Advisor and Senior IT
Lead Auditor with over 20 years of progressive experience in all domains of ICT.
• Program and portfolio management, complex project management, and service delivery, and client relationship management.
• Capable of providing invaluable information while making key strategic decisions and spearheading customer-centric projects in IT/ICT in diverse sectors.
• Displays strong business and commercial acumen and delivers cost-effective solutions contributing to financial and operational business growth in international working environments.
• Fluent in oral and written English, German, and Arabic with an Professional knowledge of French.
• Energetic and dynamic relishes challenges and demonstrates in-depth analytical and strategic ability to facilitate operational and procedural planning.
• Fully conversant with industry standards, with a consistent track record in delivering cost-effective strategic solutions.
• Strong people skills, with proven ability to build successful, cohesive teams and interact well with individuals across all levels of the business. Committed to promoting the ongoing development of IT skills throughout an organization.
Post a Comment