Managing a software development team is a job that hasn"t got easier through the years. Since the Agile Manifesto, in 2001, many software development companies and teams have tested many of the Agile methods and techniques successfully. Also known as Extreme Project Management (XPM), this approach to project management mainly addresses the aspect of changing requirements. It will increase the level of adaptability in a development team, but it will decrease that of predictability.
The lack of team predictability is, indeed, the downside of Agile methodology. This article talks about how Agile theory works in XPM and provides some, hopefully, helpful examples of how it can translate into successful projects for the team and profit for the organization.
First of all, XPM is not intended for any team. As specified in the Manifesto, we"re talking about self-organized teams, formed of small numbers of senior developers, working on projects of low criticality, where requirements often change. That"s why we would need a team culture that responds to change - a communicating, cross-functional team.
The roles in Agile teams are also important. An Agile team does not have the classical manager and its members have the ownership of their work. The Scrum Master is the team"s manager, and his role is that of a coach. He has organizational skills, obtains resources for the team and leads the team towards achieving its goals. Other roles in the Agile team would be: the Domain Expert, The Technical Expert, the Independent Tester, the Product Owner, the Stakeholder. As we are about to see later, each of these members will focus on different aspects of the project they are all involved in and this is the real challenge of the Agile Team.
I"ve divided the aspects that Agile methods are intended to enforce in a team, into three categories:
As mentioned above, XPM works with constant and productive team communication. Following Agile procedures, such a working environment can be built to assure evolution and process optimization.
And these are the Agile tools: Iteration Planning, Poker Planning, Velocity Tracking, Sprint Retrospective. Team efficiency is ensured by the daily Scrum meetings (stand-ups) and the very short feedback loop that makes a sprint (working cycle) very adaptive. The Agile team will also be focused on quality, by practicing continuous integration, unit testing, pair-programing, code review and code refactoring, domain driven design and test-driven development.
Agile methodology teaches us many things and approaches development from different points of view. I think one of the most important dimensions would be the Agile Undefined Process - the principle that according to which an Agile process or project is not at any point fully defined. It also refers to the concept of Agile Modeling: documentation, architecture and requirements that can change at any time and that must always be clear and transparent. It is also the principle that emphasizes the difference between Development Release and Production Release, or the difference between team velocity and meeting product release commitments.
As I mentioned above, Agile is not about being predictable. Its focus is not procedures or artifacts, but methodologies for people. In Agile terminology these are called Crystal Methods: frequent release of usable code, reflective improvement, easy access to expert users, automated tests.
Another important Agile dimension is Feature Driven Development. This presents best practices from client-value functionality perspective: domain driven development, individual code ownership, regular releases and visibility of progress and results. And with these best practices we"re getting closer and closer to the other side of Agile: expenditure of resources and on-time delivery.
In Agile, the management of time, quality and cost is called the Dynamic System Development Method. It talks about focusing on the business need, delivering without compromising quality, always demonstrating control by building incrementally and communicating continuously and clearly. It introduces the term prioritization (the musts, the shoulds, the coulds and the won"t haves).
Even though I"ll be presenting the use of Scrum in XPM, there are the following guidelines from Kanban methodology that come to complete very well the point I"m trying to make in terms of delivering on time and controlling resources. And these guidelines could be summarized by the phrase: "Stop starting and start finishing". Meaning that the team should agree to pursue incremental change and respect current process, roles, responsibilities and titles.
So, I"ve mentioned that Agile doesn"t focus on procedures, but on people and methods for people. Well, there is this last Agile dimension that does concentrate on what"s being developed instead of how. And this is known as Lean Software Development - policies and procedures written for the purpose of controlling expenditure of resources. Some of these policies are: eliminate waste, decide as late as possible, deliver as fast as possible, see the whole picture, build integrity in (the perceived integrity of a system, by the client, is based on how it"s being advertised, delivered, deployed, accessed, on how intuitive it is, on its price and how well it solves problems).
We"ll go back, now, to that point where I mentioned that different members of the Agile team would have different interests when building projects. Of course everyone is doing their best job and understands and respects the Agile Project Scope (what software to build and deliver). But, while the team members are interested in the Extreme Programming (XP) engineering methods and practices and writing quality code, the Scrum Master is interested in keeping up with the unpredictability of system requirements, while at the same time being able to measure the velocity of his team. The Product Owner, on the other hand, in not interested in the velocity of the team, nor in the quality of the code. He would like the team to be able to make accurate production release estimations. In other words, the Product Owner, as well as the Stakeholders, would like the team to be ... predictable.
In order to be able to predict Production Release, first, a team must be able to predict Development Releases. For this we have the Scrum Project Management tools: poker planning, velocity tracking charts and sprint retrospectives. Now, let"s go through some concrete examples of how Scrum and XP could work together and help us reach the goal of predictability.
Usually, you"ll find more articles talking about the differences between Scrum and XP. Even though they both focus on producing working software deployments in short time and emphasize the importance of frequent communication between the teams, these two seem to be defined as opposite approaches of developing systems. Here are some concrete differences:
Knowing some of the most important differences between Scrum and XP, here are some concrete tools that merge the advantages of the two methodologies, so they can help us with the issue of unpredictability:
A Scrum team comprises all the people necessary in delivering working software. This means developers, testers and business analysts working toward a common goal. Even though we"ve embraced the Agile principles for development, release management and project planning are still done according to the Waterfall model. The Agile realities of enterprises have diverged from the original ideas described in the Manifesto and translated into a hybrid approach to application lifetime management called Water-Scrum-Fall.
Water - requirements and specification (all the documentation needed, kept up to date)
Scrum - design and implementation (engineering practices)
Fall - verification, maintenance (automated testing, release and deployment)
XPM is about creating qualitative, working deliverables that provide the highest possible business value while reducing the risk of failure. With Water-Scrum-Fall you are slowly making Agile change from team based Agile to enterprise Agile and driving the benefits of Agile into the organization. By embracing the benefits of both Agile and Waterfall development methodologies you take control of how the team connects with the other parts of the organization, incrementally reducing waste and increasing predictability in terms of estimations and delivery.
In Scrum, velocity is how much product backlog a team can handle in one sprint. This can be estimated by analyzing previous sprints, assuming that team composition and sprint duration are kept constant. Velocity reports are used in Sprint Planning meetings to define the following sprint. Once established, velocity will be used for release planning.
Velocity measurements charts:
With XP, sprints are flexible and new stories may be added during the sprint. This makes velocity tracking more difficult and Burndown charts almost impossible to keep. What should happen is that, when a new task is pushed during the sprint, another one is removed. This way the amount of story points assigned per sprint remains as planned. If this does not happen, and, while new tasks keep being added, none or less are being removed, the team may not be able to complete the sprint as planned, and thus be unable to meet its delivery commitments.
The XPM Velocity Tracking equation:
Planned (sp) + Added (sp) - Removed (sp) = Assigned (sp) = Burned (sp)One important principle of XP is collective code ownership: ensuring that you have more than one pair of eyes looking over one piece of code. The purpose of this approach is not only to deliver quality code, with fewer bugs, but also to share the knowledge amongst all the team members and for developers to get the chance to learn good ideas from their colleagues.
In order to make sure that the cost of reviewing code does not exceed the benefits, here"s an idea of what would work and when.
First, you may be familiar with the phases of an Agile Team: Forming, Storming, Norming and Performing.
Depending on where the team is at the moment, some code review approaches apply more than others.
During the Forming period it is indicated that team members pair and work together on projects. This way, juniors can work with seniors, members with more experience on the project can share the knowledge and the team gets more productive than when individuals work alone.
When the team is in the Norming phase, code review sessions with the whole team are suited. Now"s when the team is setting its coding guidelines and standards and some major collective decisions have to be made.
Finally, if the team is mature and in Performing mode, working individually would be more efficient than having two people working on the same piece of code. Peer-review is the code evaluation that should still be practiced in this case.
The last, but also the most important rule of XPM is making sure we put into practice as much as possible, as soon as possible. Every team meeting"s output should finalize with a set of conclusions and action items and no sprint retrospective should set new goals for the team as long as previous ones haven"t been reached. We want to keep the team aware, responsible and focused.
by Ovidiu Mățan
