Disciplined Agile

Mainstream agile methods would suggest that we should have one product owner, being the “one” voice of the customer for matters related to release/iteration scope, priorities, and requirements clarification.

The reality that I see on most enterprise agile projects is that the product owner cannot possibly manage the work item list themselves.  In fact, they are often not the best person to do this prioritization.  I wish it were as easy as managing epics and user stories.

On my current project, we are in the process of taking ownership of a very large application built offshore.  In DAD, we would describe this as the Transition phase of the product as we deploy the solution to our stakeholders.  We will take over the build, deployment, support and enhancement going forward.  This is a team of 20+ with responsibilities spanning development, infrastructure, and devops.  Due to the complexity of the rollout we are doing it over a number of Transition iterations.

A simplistic view would suggest that the Program Manager is our product owner.  At the end of the day he may have ultimate responsibility, but he is not collocated, and deals with the larger issues of the project, such as vendor management, governance, funding, resourcing, and other related issues.  He delegates responsibility for the details to domain leads for the business, development, infrastructure and support.

My approach as the overall agile team lead is to treat the these traditional leads as product owners.  They each have their own work items and priorities such as:

Development team:

• setting up VM images for development support of code
• determining a source code management strategy for parallel streams of maintenance and enhancements
• automation of continuous integration & deployment

Support team:

• establishing a customer support strategy, with triage process, roles, on call schedules etc.

Infrastructure/DevOps team:

• setting up automated jobs
• performance tuning

Business:

• change requests/stories
• defects

All:

• knowledge transfer between vendor and support team
• satisfying stage gate acceptance criteria
• documentation of procedures

For these work items, who is responsible for designating priorities, assigning to iterations, and iteration planning? The last question is the easiest to answer.  We let the team members doing the work do the task identification, estimating and assignment.  The other questions are a bit more tricky.  I don’t believe that any one person should determine the scope and prioriity of these diverse work items.  Rather, as team lead, I would prefer to let the team leads of infrastructure, customer support and development (traditionally might be PMs) to self-organize and advise me on their priorities and in which iteration their work items should be completed.  The summary of which is then reviewed with the Program Manager to assure alignment with the overall program’s goals.

Therefore what we are doing is co-managing the work item list with myself as facilitator.

This discussion shows some of the challenges in managing a DAD Transition iteration(s) using an agile approach.  I understand that the idea of having shared product ownership is not consist with methods such as Scrum.   However, in my world of large enterprise agile projects pragmatism trumps the agile “code”.  As Barbossa says in Pirates of the Caribbean, “the code is more what you call guidelines than actual rules“.

I’m writing this from the Agile Business Conference in London where I did a talk on DAD yesterday. Unfortunately I didn’t have much time to go into DAD in depth. A gentleman approached me today, saying that he is very interested in learning more about DAD but is not sure why it is needed with all the other methods out there,

This is a very good question, and I guess I should have been more clear in my talk. First of all, DAD is not a new method, but rather a general framework from which you can pick some “good ideas” which might makes sense for your organization or project. It also adds some structure that is missing from most agile methods. Here are some reasons that we think that the toolkit is worthwhile:

• DAD is a hybrid of leading agile methods, bringing together a set of complimentary practices from methods such as Scrum, XP, Agile Modeling, Lean, & the Unified Process
• most existing methods such as Scrum, do not have practices related to the full lifecyle (by design). Scrum for instance is focused mainly on management, rather than say, architecture. DADs hybrid approach harvests leading practices from across the lifecycle
• DAD goes beyond agile rhetoric and acknowledges that certain enterprise practices don’t go away with agile, such as the need to collaborate with other projects, enterprise authorities such as architecture, database , and PMOs
• an explicit recognition that most enterprise projects go through startup (Inception) and deployment (Transition) phases
• DAD avoids branded terminology such as “sprint” and rather uses common sense terminology that is understandable regardless of one’s methodology preference

DAD is meant to help promote and simplify proven agile practices, not replace them.  Rather than having to say “our shop does Scrum, with some XP practices, a bit of Kanban, etc…”, why not say that you are using DAD? You can choose from any of the techniques from these methods without some agilist criticizing you that “you are not doing Scrum actually because it doesn’t believe in the XYZ practice that you are using from ABC method”

If you are doing Scrum now, for instance, you could currently say that you are using DAD, as its guidance is a subset of practices you could use in DAD, As you add agile capability, and want accelerate your projects and increase quality, or add some required scaling techniques, you could draw additional ideas from DAD. BUT only if required and makes sense for you.

In summary, DAD provides a breadth of non-prescriptive guidance (good ideas that MIGHT make sense for you) with non-branded ideas that go beyond traditional agile methods to help deal with enterprise considerations that are a reality on most non-trivial projects.

Malcolm Gladwell, author of The Tipping Point, Blink and Outliers, speaking at a 2004 TED conference, offered a story of one of his favorite Americans. Howard Moskowitz is an American market researcher and Psychophysicist, which according to WikiPedia is “the scientific study of the relation between stimulus and sensation”[2] Moskowitz has worked for large conglomerates such as Pepsico, McDonald’s, AllState and Kraft and is principally known for creating the insane number of product variations you see at your grocery store.

Moskowitz determined that people often don’t know the range of options they would like to buy until someone presents them with the choice.
Moskowitz was retained by Campbell Soup Company, to help them grow their spaghetti sauce brand, Prego. With his team of researchers in tow, his team tested public reaction to forty-five different varieties of sauce. When analyzing the data, the researchers didn’t just look for the combination with the highest ratings. They believed people craved variety even if they didn’t know it. They grouped their data to look for clusters- patterns. When reporting back the executives he found people like three kinds of sauces: plain, spicy, and extra chunky.
For years the approach to gathering product requirements, consumer tastes, researchers would go into focus groups and say, “What do you want in a spaghetti sauce? Please tell us. Not once did anyone say, ‘extra chunky’, even though in their heart they craved it.” Moskowitz revealed there was no “single sauce for the market. There were sauces”
How does a product owner manage in that environment? When you read the story it’s easy for us to see the solution. “Of course we want choices. The product development team should incorporate that into their development process.” And now, admittedly this is rather common place. At the time, however, Campbell’s soup executives were astonished to hear that over 1/3 of all Americans craved chunky spaghetti sauce and no one was providing it. When the market need was met, over $600M revenue was added to the Campbell’s Soup line.

So what does this have to do with software requirements? It is a story to illustrate the folly in thinking we can always know what our client will want, specify it and then build and deliver it. Even when you are dealing with an industry as mature as consumer goods & spaghetti sauce, we see that when your product is attempting to change the category, you need experimentation in your development cycle.
MIT professor and author of Predictably Irrational, Dan Arielly, reminds us we need to have something to compare against to settle our preference.

humans rarely choose things in absolute terms. We don’t have an internal value meter that tells us how much things are worth. Rather, we focus on the relative advantage of one thing over another, and estimate value accordingly. (For instance, we don’t know how much a six-cylinder car is worth, but we can assume it’s more expensive than the four-cylinder model.

Until end-users and stakeholders have something to compare it against, they can be indecisive- slowing down projects. This explains the challenge with just getting people in a room and asking them to describe to you what they want. They probably don’t really know- even when they tell you.
Typically the approach we take when we  are unsure what it is we are building, we attempt to stress more documentation and more reviews. We’ve been taught that correcting a requirements error early in the life cycle saves costs down the line. We work to reduce our discomfort with the uncertainty by forcing a someone else to make a decision so we can then narrow in on our solution. We insist on a freeze in requirements and sometimes limiting participation because “too many cooks” spoils the broth- or sauce as it were. Unfortunately, we are ignoring the sometimes less than rational way people make decisions. All the process waving and feet stomping in the world won’t change the reality of the marke, meanwhile your competitor is giving your customer  chunky spaghetti sauce.

Attempting to be to deterministic in specifying our project requirements usually stifles creativity. Roger Sessions of ObjectWatch, Inc. Uses the terms directed and non-directed methodologies. Equating directed methodologies to playing the childhood game, “Hot-or-Cold”, where there truly is only one possible solution. Where as Poker is a non-directed methodology where there are multiple ways to win. Just because your client specifies the need for a straight flush doesn’t mean he won’t be happy with two pair if he wins the pot.

The practices within the application life cycle that best provide some allowance for this behavior include:

• Simulation– Using rough cut, working software simulation tools such as iRise can give clients multiple usage scenarios to evaluate.
• Integrated product design– Nothing works as well as having the entire product development team deeply involved from product concept to launch, collaborating in real time- seeing the implications of their decisions and indecision.
• Iterative development cycles– Knowing the limits of prediction, rapid feedback of working software allows for course correction in architecture and product direction before too much is sunk.
• Component Architectures– Understanding where the range of diversity in our users tastes lies then requires us to build in that flexibility.

Gladwell’s story also reminds us that solutions are a continuum. A variety of different end products and combinations will make our clients happy. Boiling down to the lowest common denominator ignores the individual and organizational diversity. It may seem logical to get the market to standardize for the best greatest use, but if that’s how we made decisions we’d all be driving Model-T’s. Thank you Mr. Moskowitz for recognizing the need for spicy sauce. Now go expand your customers range of options. Go find your secret sauces.

?

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.

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.