Archive
Is your agile project environment “fragile”?
It never ceases to amaze me how many people and organisations seem to think that to become agile they just need to sprinkle some magic agile “pixie dust” around their projects and all will be transformed.
In my latest blog for UPMentors and IBM developerWorks, “Is your agile project environment “fragile?”, I try to dispel some of the notions and highlight the discipline required for an organisation to adopt agile practices and achieve Disciplined Agile Delivery.
Non-Solo Development
Last month I gave a presentation on DAD at the Innovate Comes to You conference in Long Beach. During my review of the DAD practices, someone asked a question if non-solo development (aka pairing) was a cost-effective practice. Which made me realize they had never tried it. Having been a programmer now for 28 years, I’ve cut a lot of code. During which, I’ve done a lot of solo-development and non-solo development, and I’d have to say that I would highly recommend non-solo development in most contexts.
Non-solo development produces higher quality code, code with fewer defects, and less technical debt. Most all of us have seen the chart that shows the cost of a defect growing exponentially during the development lifecycle. Fixing a bug in a maintenance mode requires someone (or a pair) to wrap their brain around often complex algorithms in order to understand the logic, make the repair, and not break something else. This is far more costly later, rather than when the code is “fresh in your head”. Having a second set of eyes present while code is being authored often catches these bugs before they happen.
Having two minds make design decisions in real-time during coding, greatly reduces future technical debt. Furthermore, model storming with the team will improve overall architecture and design and result in less refactoring work and technical debt. If you’ve ever been on a project that has suffered from the costs of technical debt then surely you can realize the benefits of preventing technical debt before it’s incurred.
Non-solo development usually increases productivity, motivation, and morale of developers. From my own personal experience with pairing, I’ve found it increases productivity in most situations. Left alone, I’m more prone to lose focus, surf the net, think about non-work things, etc. When engaged with a partner I tend to be more driven, motivated, and focused on completing development tasks. Team work and collaboration is often more rewarding then coding by one’s self. Tag teaming the keyboard helps to keep the pace and reduce fatigue.
Many projects will find they need fewer code reviews with non-solo development, due to actual code reviews happening in real-time. If you try non-solo development on your team, you’ll find that certain combinations of individuals have better chemistry and thus better throughput and quality. In most situations you should try to keep these bands together jamming out great code, unless there is a need to grow the skills of more junior resources.
Non-solo development is an excellent way to grow development skills. Matching up senior developers with junior developers is a great way to grow your talent pool. In these situations, I prefer to have the junior developer do most of the “driving” with the senior developer in the “back seat”. It’s a great way to bring new resources up to speed with architecture, design, and the state of the code.
It’s also highly effective during maintenance. In these situations it’s good to group resources less familiar with code with resources more familiar with the code. By fixing bugs and developing new code together, tacit knowledge and skills are transferred more readily. Non-solo development is a key ingredient to growing skills and improving the capabilities of your personnel and your team.
Non-solo development by nature increases the “bus factor”. If tacit knowledge gained by authoring code is not shared by more than one developer, if that developer is “hit by a bus” or leaves the project, that knowledge is lost. Hopefully code is well commented, clearly written, and may even be externally documented (though I question the value of creating external code documentation in many cases). However, even well described code can take time to understand how it works, especially to the level needed to make changes without introducing new bugs.
This is why non-solo development is effective in reducing this dependency on a single developer, on a single point of failure. Knowledge redundancy achieved by sharing the tacit knowledge of how various code modules or sub-systems function, helps build a more collaborative, fault-tolerant environment. Trying to capture this tacit knowledge in documentation and to keep it up to date increases costs and decreases productivity.
So is solo development always bad? No, I’ve written a lot of great code all by myself. There have been projects where I understood the business, knew what software it needed, grasped how to architect the solution, could see much of the design details in my head, and just coded like the wind. No communication to slow me down, heck there were times where I coded 18-20 hours a day for a week at a time. I was able to whip out tremendous value in a short period of time. But that kind of pace is not sustainable over months. Nor is the single great developer scalable to large projects. Plus, who will maintain all that code, once that developer moves on to the next project.
At some point, most projects take a team of people. As mentioned above there are big benefits in combining team members and avoiding solo development. Especially with respect to quality during green field development where considerable design decisions are being made as new code is developed. The whole can be greater than the parts; the power of collaboration and non-solo development will improve quality and keep the velocity churning. If you’ve never tried non-solo development on your team, you should. You’ll never experience the benefits if you don’t give it a shot.
Handling business change management on DAD projects
I had a very interesting discussion today with Bob Ouellette about dealing with business change management on agile projects. In his organization they use the ADKAR model to manage their change. Interestingly enough, so did I on my last project. This was a huge project and we had several people working on communications and change management working directly within our agile teams. It worked extremely well. In fact, they were some of the strongest supporters of the agile practices we incorporated. Unlike Scrum’s backlog, in DAD we call it a work item list. As such, it can include work items that go beyond requirements/user stories. The product owner added items to the work item list to represent the work of the communication and change management folks. We tracked the progress of these work items during the iterations on the task boards just like any other work item.
In DAD, team contributors are called team members. We don’t use specific roles names, such as business analyst as that would discourage any tendency to contribute in areas outside one’s official role. In DAD projects, it is common to supplement your team with people beyond typical roles such as developers and testers, with other team members that support the implementation of the entire solution. For non-trivial projects, people are often required to support the business aspects of the solution, not just technical. Contrary to some advocates of mainstream agile methods, not everyone on an agile team needs to write code.
Chapters 1-4 of DAD book available for review on Safari Roughcuts
First 4 chapters of our book on DAD available on Safari Roughcuts for review. http://bit.ly/mY8daa
Do agile teams need to work with enterprise architecture authorities?
Some would argue that effective agile teams have all the skills internally to deliver the solution. Is it practical to expect the project team to have control over all aspects of the project such as architecture, database designs and so forth? Or should agile teams take some time to consult with authorities such as PMOs (to understand required governance), DBAs (to evolve a common database, or find existing data sources), and Enterprise Architecture groups (to discover existing assets for reuse, or contribute new ones)?
DAD workshop in Markham Nov 14-16, 2011
Mark will be teaching IBM’s 3-day workshop on Advanced Disciplined Agile Delivery in Markham Nov 14-16. You can register here.
Mark Lines speaking in London October 5th 2011
Mark will be speaking on Disciplined Agile Delivery at the Agile Business Conference 2011 in London October 5th.
Disciplined Agile Delivery: An Introduction white paper
Topics covered:
- Context counts - The Agile Scaling Model
- People first – People, and the way they interact with each other, are the primary determinant of success for a solution delivery project.
- Learning-oriented – The DAD process framework promotes the ideas that team members should collaborate closely and learn from each other, that the team should invest effort to learn from their experiences and evolve their approach, and that individuals should do so as well.
- Hybrid – DAD adopts and tailors strategies from Scrum, XP, Agile Modeling, UP, Kanban, and many others. It addresses many of the issues Mark Kennaley discusses in SDLC 3.0.
- IT solution focused – DAD teams produce potentially consumable solutions every construction iteration. This extends Scrum’s “potentially shippable” strategy to explicitly address usability/consumability plus the fact that we’re really delivering full solutions not just software.
- Goal-driven delivery life cycle – The DAD lifecycle is focused on delivery, not just construction. Furthermore it is goals-driven, the DAD process framework suggests various strategies to fulfill those goals but does not prescribe specific practices.
- Risk and value driven – The DAD lifecycle is risk and value driven. It extends Scrum’s value-driven lifecycle which produces potentially shippable software each sprint/iteration so that it explicitly includes light-weight milesstones such as ensuring stakeholder consensus as to the scope of the project early in the lifecycle, proving the architecture with working code early in the lifecycle, ensuring sufficient functionality exists before transition, and ensuring production readiness before actual release of the solution.
- Enterprise aware – The DAD process framework promotes the ideas that DAD teams should work closely with theirenterprise architecture groups to ensure they leverage and evolve the existing infrastructure, adopt and follow corporate guidelines, and work to the overall organizational vision. DAD teams are self organizing with appropriate governance.
