Anyone who has ever been responsible for managing software development projects knows that software is not easy. Successfully coordinating and dealing with: Project sponsors, Customers, Team members, Technology issues, and most importantly the ‘ever changing requirements’ challenges even the most experienced project leader.
Leading projects in an environment that embraces both rapid delivery and change can prove even more daunting. Yet individuals with the desire to change the fundamental rules of the software game and accept the empirical nature of software development are faced with numerous opportunities. In order to capitalize on the evolutionary nature of agile development, today's leadership community must also focus on five key aspects associated with of agile development:
Courage, Context, Course, Cadence, and Cost.
Software development requires many interfaces - customers, other project teams, customer support, professional services, external stakeholders, human resources, and many more - and the confidence to step up to the plate and be willing to enact positive change in the face of tradition can be a risky, but rewarding experience.
Agile development is definitely not for the faint of heart. This does not mean that project management won't ultimately be simplified, but rather that any new way of doing business requires practice and hard work. Agile leaders cannot be afraid to fail, especially during early iterations. With agile development, at least failures are typically limited in scope to a few weeks, at which point you can reevaluate the situation and adapt accordingly.
These early iterations should be used to learn, adjust, and stabilize. Teams, and people, generally get good at what they practice. In agile development, planning, estimating, testing, and delivery, occur every few weeks as opposed to once every year. As a result, teams quickly develop a rhythm. By focusing on removing obstacles that get in the way and allowing this rhythm to emerge, agile leaders set the stage for improvement, predictability, and success. While still in the heat of software delivery battle, a vast majority of agile teams look back after six months, see the improvement, and wonder how they ever could have successfully delivered software any other way.
It is important to steer and manage actions and decisions within an overall business context. While functional value can oftentimes drive the details of a project, business values need to help drive project goals. Force hard decisions about the business and project context as early as possible. Get as simple as possible answers to key questions such as:
• What is the vision for the project?
• What are the primary goals and business drivers of the project?
• What are the values that should drive key project and product decisions?
• What are the expectations of project sponsors and stakeholders?
The answers to these questions serve as the basis for future decision-making, as well as a thread that can prevent a project from spiraling out of control. Additionally, the degree of visibility afforded these priorities can serve as a foundation for managing conflict and stakeholder negotiations.
One way to make sure everyone sees the answers to these questions is to print them on a single page or project web page, and keep them visible throughout the life of the project. These answers often serve as a bar to which you will be held accountable.
Context and course are complementary ideals. Whereas context defines overall circumstances, course defines direction and progress. Although some agile approaches reference not looking in detail beyond one to two iterations, it is wrong to assume that longer range planning is not necessary or valuable. Longer-term software plans serve as a roadmap for important interim business and project decisions.
Iteration, milestone, and release plans remain critical components in planning and measuring progress. As you plan further out, confidence levels diminish, but a minimum three- to six-month roadmap serves as a continuous reality check in the face of a changing environment.
A concerted effort is needed at least once every iteration to revisit objectives, reconcile overall direction, review time-frames and deadlines, and communicate variances. In agile development, change is accepted and even fostered for business reasons, so in addition to delivering early and often, be prepared to communicate early and often. Unlike traditional projects environments where the feedback loop can span quarters or even years, successful agile project teams communicate directly with key business and management stakeholders as often as each iteration.
Cadence (Rhythm)
The concept of cadence or rhythm is one of the most beneficial effects of agile development. Similarly, teams' deep grasp of iterative and incremental delivery in its complete sense can serve as significant risk mitigator. Instead of delivering once a year or more, agile teams deliver working, tested, installable software every iteration.
In this type of environment, unexpected loose ends greatly diminish, defects are much easier to manage, integrated builds are second nature, and production deployment becomes much more streamlined and foolproof. This is not to say that some problems will not arise, but those that do will be much more manageable.
Even agile development cannot escape the associated financial implications of software development. The challenge, and advantage, of agile development is the opportunity to justify the cost with business value and customer benefit throughout the process, as opposed to once at the very end. Here the goal being to achieve the highest possible returns earliest in the development cycle.
While you may not have the same direct influence over business benefit that you do over cost, the opportunity to allow the business to extract value sooner rather than later, continuously align business and technology goals, and adjust to changing business dynamics is of tremendous value.
While the cost model for most agile development projects is fairly straightforward, "cost per iteration" is not something that many organizations have either experienced or understand. Fortunately, many consulting companies and software organizations have made the transition to a simplified project costing model, multiplying the approximate cost per person for the entire team by the length of an iteration to derive ongoing financial impact (e.g. Rs.80,000 per iteration). While this is not as sophisticated as traditional staffing and resource allocation models, this type of analysis and justification can be just as accurate.
Adaptive v/s Predictive methods:
Agile methods are sometimes characterized as being at the opposite end of the spectrum from "plan-driven" or "disciplined" methodologies. This distinction is misleading, as it implies that agile methods are "unplanned" or "undisciplined." A more accurate distinction is to say that methods exist on a continuum from "adaptive" to "predictive". Agile methods exist on the "adaptive" side of this continuum.
Adaptive methods focus on adapting quickly to changing realities. An adaptive team will have difficulty describing exactly what will happen in the future. The further away a date is, the vaguer an adaptive method will be about what will happen on that date. An adaptive team can report exactly what tasks are being done next week, but only which features are planned for next month. When asked about a release six months from now, an adaptive team may only be able to report the mission statement for the release, or a statement of expected value vs. cost.
Predictive methods, in contrast, focus on planning the future in detail. A predictive team can report exactly what features and tasks are planned for the entire length of the development process. Predictive teams have difficulty changing direction. The plan is typically optimized for the original destination and changing direction can cause completed work to be thrown away and done over differently. Predictive teams will often institute a change control board to ensure that only the most valuable changes are considered.
Agile methods have much in common with the "Rapid Application Development" techniques from the 1980's.
Examples of Agile Development Techniques:
1) Extreme Programming:
Extreme Programming (XP) describes four basic activities that are performed within the software development process.
Coding
The advocates of XP argue that the only truly important product of the system development process is code (a concept to which they give a somewhat broader definition than might be given by others). Without code you have nothing. Coding can be drawing diagrams that will generate code, scripting a web-based system or coding a program that needs to be compiled.
Coding can also be used to figure out the most suitable solution. For instance, XP would advocate that faced with several alternatives for a programming problem, one should simply code all solutions and determine with automated tests (discussed in the next section) which solution is most suitable.
Coding can also help to communicate thoughts about programming problems. A programmer dealing with a complex programming problem and finding it hard to explain the solution to fellow programmers might code it and use the code to demonstrate what he or she means. Other programmers can give feedback on this code by also coding their thoughts.
Testing
One cannot be certain of anything unless one has tested it. Testing is not a perceived, primary need for the customer. A lot of software is shipped without proper testing and still works. In software development, XP says this means that one cannot be certain that a function works unless one tests it. This raises the question of defining what one can be uncertain about.
- You can be uncertain whether what you coded is what you meant. To test this uncertainty, XP uses Unit Tests. These are automated tests that test the code. The programmer will try to write as many tests he or she can think of that might break the code he or she is writing; if all tests run successfully then the coding is complete.
- You can be uncertain whether what you meant is what you should have meant. To test this uncertainty, XP uses acceptance tests based on the requirements given by the customer in the exploration phase of release planning.
Listening
Programmers do not necessarily know anything about the business side of the system under development. The function of the system is determined by the business side. For the programmers to find what the functionality of the system should be, they have to listen to business.
Programmers have to listen "in the large": they have to listen to what the customer needs. Also, they have to try to understand the business problem, and to give the customer feedback about his or her problem, to improve the customer's own understanding of his or her problem.
Designing
From the point of view of simplicity, one could say that system development doesn't need more than coding, testing and listening. If those activities are performed well, the result should always be a system that works. In practice, this will not work. One can come a long way without designing but at a given time one will get stuck. The system becomes too complex and the dependencies within the system cease to be clear.
One can avoid this by creating a design structure that organizes the logic in the system. Good design will avoid lots of dependencies within a system; this means that changing one part of the system will not affect other parts of the system.
Team creation
Scrum believes that a development team should perform as a sport team, every team member working independently but towards the same goal. Scrum suggests that a team has a maximum of 6 - 7 members. The team facilitator is called the Scrum master. His/her job is to implement and manage the Scrum process in the project.
The Scrum team as a whole defines the practices, meetings, artifact and terminology of SCRUM for the team, and the Scrum Master ensures adherence to these "norms" identified. Scrum masters focus most of their time in managing outside interference for the Scrum team and solving outside impediments or ‘Blockers’ that cannot be solved by the Scrum team.
Backlog creation
There are 3 types of backlogs:
Product Backlog –
Acts as a repository for requirements targeted for release at some point. These are typically high level requirements with high level estimates provided by the product stakeholders.
Release Backlog –
Requirements got from the product backlog and prioritized for an upcoming release. The release backlog contains more details about the requirement and low level estimate which are usually estimated by the team performing the work.
Sprint Backlog –
At the beginning of each sprint (period), the team has sprint planning with an end result being a backlog of requirements/sub-requirements that the team anticipates completing at the end of the sprint. By completing, that means fully coded, tested and documented. These are the items that the teams will "Burn down" throughout the duration of the sprint. The sprint backlog breaks the release backlog requirement into manageable chunks that can be accomplished typically in 8 - 16 hrs.
The whole project gets divided into periods of time with a maximum duration of 4 weeks. One period is called a Sprint and every team gets a backlog to execute within the given Sprint.
During the sprint, the team conducts daily scrum meetings.
The meetings are held in the same place at the same time every work day.
The meetings don’t last for more than 30 minutes.
A scrum master is appointed.
The scrum master is responsible for asking every team member the following three questions:
- What have you done since the last scrum meeting?
- What has impeded your work?
- What do you plan on doing between now and the next scrum meeting?
Conversation is restricted to the team members answering the above questions.
Meetings can be established for immediately after the scrum meeting based on answers to the above questions.
The scrum master is responsible for making decisions immediately, if required to remove impediments to progress.
The scrum master is responsible for noting impediments that must be resolved external to the meeting and causing them to be removed.
The Scrum development process consists of 5 major activities “Review release plans”, “Distribution, review and adjustment of product standards”, “Sprint”, “Sprint review” and “Closure”.
Sprint
The Sprint phase is where the software development takes place. A Sprint consists of the following sub-activities: Develop Wrap, Review and Adjust. This phase has no sequence. Sometimes a backlog item must be developed, wrapped and reviewed and sometimes a backlog item must be only reviewed or adjusted. It totally depends on the backlog item.
Each Sprint is followed by a Sprint review. During this review the software developed in the previous Sprint is reviewed and if necessary new backlog items are added. The reviewers consist of project stakeholder, managers, developers and sometimes customers, sales and marketing.
The activities, Sprint and Sprint review are repeated until the product is deemed ready for distribution. Then the project goes into the closure phase where the product is made ready for release and distribution.
In this stage activities like last debugging, marketing and promotion take place. By finishing this activity the project is closed. Because of the unpredictability of the software development process it’s not possible to define exactly when this activity will take place and so the project may take shorter or longer than planned. But by using the controls given by Scrum one can make calculations on the duration of the project. More about controls and this kind of calculation can be found in the “Scrum Controls” part.
Agile Documentation
In the software industry the norm says that: "You need to document it properly first to be able to code it later. That's why you need architects and designers that prepare the documents that programmers will base their work on."
For example if you write a document in 1 hour and you need to share that knowledge with 2 other people you will have to spend at least another hour explaining that document to those 2 people (this is excluding the document reviews). Meaning that in a good scenario you will spend 3 hours to imperfectly transfer knowledge to 2 people that you could by talking to them face-to-face during one hour.
Why you need to spend time talking to people even after writing the document is that people are not perfect writing documents nor understanding what someone else wrote. When people write they have their own context, their own knowledge, their own assumptions, etc. Not all those get written (it would simply take too long and most of them would not be relevant anyway), many times some critical knowledge does not get to the paper. When that happens the reader will not be able to understand the text without talking directly to the writer and spend time discussing some of the not so obvious knowledge behind what is written. All this takes time.
“Whoever needs the information writes the document”. Why?
1. The person who writes the document (the one that needs the information) will go through the process of understanding the information while she writes the information (this is the main purpose of this rule)
2. The person often needs the information because she interacts with the project team, in this situation writing the document (and all the information exchange with the team that comes with that) will also help that person commit to help the team solve the issues she will be asking them to solve
3. In the process of researching the document the person shares a lot more information with the team than what gets written. This is important because both the writer and the team get to share information they would otherwise not.
Trade-offs
Documentation can have bigger impacts in the projects than we normally think:
1. Quality work: including testing, reviewing documents, discussing bugs, etc.
2. Feature work: implementing, thinking about features, finding which requirements to implement, reworking (fixing bugs), etc.
3. Documentation: writing information down for generations to come
4. Face-to-Face communication: exchanging information, team building, etc.
Often in software projects Quality is traded for Features/Scope. This approach comes from the fact that we are forgetting that we can actually trade other things out before we have to trade out quality. In fact we can trade out for example documentation or face-to-face communication.
You must plan what you want to trade-off in a software project so that you know what matters when the time comes to drop something, if you don't plan the trade-offs you will end-up trading-off quality like most people - even when you could be trading off documentation, especially the one that delivers no value to the customer.
