Disciplined Agile

There is no such thing as a “best practice”, except perhaps from a marketing point of view.  All practices (and strategies) are contextual in nature.  In some situations a practice works incredibly well and it other situations a practice can be the kiss-of-death.  Two of the philosophies behind the Disciplined Agile (DA) tool kit are that choice is good and that you should understand the trade-offs of the options available to you.  In short, practices are contextual in nature and you should strive to adopt the ones that work best for the situation that you find yourself in.

Let’s work through an example.  A hot button for many people are strategies around cost estimation, typically used for budgeting and forecasting purposes.  In DAD initial estimation is addressed by the Plan the Release process goal, the goal diagram for which is shown below.  As you can see with the Estimating Strategy factor there are several options available to you.  We’re not saying that these are all of the potential estimating options available, but we are saying that this is a fairly good representative range.  The arrow on the left-hand side of the strategies list indicates that the strategies towards the top of the list are generally more effective for initial planning than the strategies towards the bottom of the list.  Your mileage may vary of course.

The following table summarizes the trade-offs involved with two of the estimating strategies, in the case formal point counting (such as function points) and an educated guess by an experienced individual.  One of the reasons why Choose Your WoW! is so thick is that much of it is tables like this communicating the trade-offs of the hundreds of practices and strategies encapsulated by the toolkit.  As you can see, there are advantages and disadvantages to both strategies.  You can also see that there are situations where each strategy potentially makes sense.  Although you may not like a given strategy, I personally abhor formal point counting, you should still respect the fact that the strategy is viable in certain situations (perhaps not yours).

There are several reasons why DAD’s goal-driven approach is important:

1. It makes your choices explicit.  If your team wants to truly own your process then it first needs to know what choices are available to it.
2. It makes it clear that practices are contextual in nature.  No practice is perfect for all situations, every single one has advantages and disadvantages.  Are you choosing the ones that are most appropriate for your situation?
3. You can have more coherent discussions of the trade-offs that you’re making.  We have endless religious battles in the IT industry around process-related topics.  This often happens because people choose to focus on the benefits of their favorite practices and to downplay the disadvantages (or worse yet are oblivious to them).  To help your team move to more effective practices it’s important to recognize the trade-offs involved with each, to then discuss them rationally, and then decide to adopt the strategy that is most viable given your situation.  Note that this doesn’t necessarily mean that you’re going to adopt the best practice from the start, but that instead you’ll adopt the best one that you can right now.  Later on, perhaps as the result of a retrospective, you’ll decide to make improvements to your approach (in the case of process factors where the strategies are ranked by effectiveness, your team may choose to adopt a strategy higher in the list).
4. Improves the effectiveness of retrospectives.  During a retrospective it is fairly straightforward to identify potential problems that you’re facing, what isn’t as easy is identifying potential solutions.  You can improve retrospectives by having these process goal diagrams available to you to suggest potential strategies that you should considering adopting.
5. You can avoid reinventing existing practices.  Many very smart and very experienced people have found ways to deal with the same challenges that you’re facing today.  Furthermore, many of them have shared these strategies publicly.  If you don’t know that these strategies exist you are at risk of wasting time reinventing them, time that could be better spent adding real value to your organization.
6. It enables scaling.  Teams in different situation will make different process decisions.  Although teams at scale, perhaps they are large teams or geographically distributed, will follow many of the same practices as small co-located teams they will also adopt a few strategies that make sense for them given their situation.   DAD’s process goals provide the insight that teams need to understand how they can address the challenges associated with the scaling factors that they face.

For a more detailed discussion about the challenges around “best practices”, you may find the article Questioning Best Practices to be an interesting read. 

A few weeks ago one of my customers asked me for advice about daily standup meetings (also called Scrum meetings, morning meetings, or better yet coordination meetings).  Her feeling was that her teams could become more disciplined in their approach to coordination meetings so she asked if it would be possible to see how teams in other companies run their meetings.  I indicated that there are a lot of good videos on YouTube and that I would write something up soon in a blog posting.  So here goes.

1. Put your meeting strategy on the wall.  Put the rules (see below) on the wall in the space where you hold your coordination meetings.  If you have virtual meetings online, capture them there (in a wiki for example).  We call things like this information radiators in agile.
2. Coach people.  It takes time to build up effective meeting skills.  At first you’ll want to coach people publicly within the team so that everyone can learn.  After awhile, if someone is still struggling (perhaps they’re often late to the meeting or aren’t sufficiently focused) you may want to coach them privately.
3. Call it a coordination meeting.  Terms such as “stand up meeting” or “Scrum meeting” aren’t very clear, but “coordination meeting” is.  By using clear terminology you make your expectations regarding the purpose of the meeting crystal clear, thereby reducing the chance for confusion.
4. Set some rules.  As a team, discuss what how you intend to run these meetings.  Potential rules you should consider adopting include:

• Arrive on time.  ‘Nuff said.
• One person talks at a time.  There shouldn’t be side conversations going on, not only is that disrespectful it results in those people being distracted from coordinating with the rest of the team.
• Come prepared.  As a meeting participant you need to know how you’re going to answer each question before you get into the meeting.
• Define what you want to discuss.  There are many different questions or issues that you can discuss in coordination meetings.  Scrum suggests “What did you do yesterday?”, “What will you do today?”, and “What’s blocking you?”.  Other questions could be “What did you learn today?”, “What will potentially block you?”, “What value did you deliver since the last meeting?” and many others. 
• Someone different leads each day.  A common strategy is to rotate the responsibility of running coordination meetings between team members.  This is a great learning experience for some people and certainly helps everyone to recognize how these meetings could be run more effectively.
• Stay focused.  The goal is to coordinate as a team, and the easiest way to do so is for everyone to focus on that goal.  So stay off your phone, don’t be reading email, don’t be holding side conversations, and only focus on the issues/questions you’ve agreed to as a team.
• Stand at first.  Having people stand up tends to keep meetings short but can prove to be artificial (I’ve been on coordination calls where people working from home or other locations have been asked to stand, yikes). 
• Coordinate around a task board.  When you gather around a task board much of the status information that you may want to communicate to the meeting is provided by the task board itself.  This provides opportunity to streamline your meeting process.

Here’s a few interesting videos that I found on YouTube:

1. How to Hold a Daily Standup. This short video provides several good tips for holding a standard “Scrum meeting”.  It suggests that people answer the three standard Scrum questions so take that advice with a grain of salt.  And the background music is a bit cheesy although fun.
2. Agile Simulation Part 20: The Daily Standup.  This video is interesting because it starts with a dysfunctional version of the meeting and then shows an effective one.  The common mistakes the video shows include running it like a status meeting instead of a coordination meeting; people coming to the meeting unprepared; discussing inappropriate issues during the meeting; showing up late to the meeting; having side conversations; one person was basically checked out and was lying down on a bean bag chair; and a non-team member started driving the conversation at one point.
3. How a Lean Thinking Company Runs a Morning Meeting. This video overviews the approach taken by an organization’s leadership team to their morning meeting.  They look at their task board, a whiteboard with stickies.  They’ve tailored their meeting to reflect the needs of what they need to coordinate, and in the video they discuss how they came to putting this meeting together.  It’s interesting to note that they are in multiple locations, so they video conference daily.
4. Lean, the Morning Meeting at Fastcap. This is another non-software development example.  This team explicitly changes the leader of the morning meeting each day to help them grow their skills.  One of the things I like about this video is that their focus is to share critical information with each other.  This includes mistakes, learnings, and any improvements that they made.  The overriding goal is to focus on learning, team building, and to celebrate their successes.
5. Dodgy Scrum StandUp. This video was purposely put together to show many of the bad habits that people may exhibit during daily stand ups.  These bad habits included not staying on topic; getting into details that most people don’t need to hear; and asking questions around implementation details instead of taking the discussion offline.  One person even threw something at another person, thereby distracting the group.  Another person showed up late, disrupting the discussion.  The team also didn’t refer to their task board (I assume that it was the task board behind people on the left hand side of the screen).

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.