Disciplined Agile

Large solution delivery teams, let’s say fifty or more people, are often referred to as programs (programmes in UK English). Such teams are often organized into teams of teams, as depicted in the diagram below.  Each of the sub teams will work on their part of the overall solution and to do so effectively there needs to be coordination between the sub teams.  On large agile teams this coordination often proves to be complex, which is why a leadership team is introduced.  This leadership team coordinates:

• Requirements. Requirements are managed by the Product Management (also called a Product Owner) team.  This team is made up of the Product Owners from each sub team.  They will meet as needed, typically several times a week. This group is the focus of this blog posting.
• Technical concerns. The Architecture (or Architecture Owner) team, comprised of the Architecture Owners from each sub team, is responsible for identifying and then governing the architectural strategy for the program.  Activities of this group include negotiating changes to the architecture vision over time, resolving disputes about technical issues between sub teams, and sharing technical learnings across sub teams.  It is common for this team to meet weekly with ad-hoc discussions occurring on an as-needed basis.
• Management concerns.  Management concerns, such as members of different teams not getting along, transfers of people between teams, and schedule dependencies will be coordinated by the Team Leads from the sub teams.  This team is often called the Product Delivery team or simply the Management team (yuck).  As with the Product Management and Architecture teams this team will meet regularly as appropriate.
• Itself.  This is the responsibility of the Program Manager. This person may be a Team Lead on one of the sub teams, although more often than not fulfilling this role proves to be a full time job.  The Program Manager will guide the overall program team, ensuring that the three leadership sub teams are working together effectively and that they are meeting to coordinate their own activities as appropriate (and typically on different schedules).

Product Management/Ownership Team Organization

The Product Owner in each sub team is a member of the Product Owner team for the program, as depicted in the following diagram.  Individual Product Owners will typically spend 80-90% of their time on activities that are directly related to supporting their sub teams and the rest of the time to requirements management activities at the program level.  The Product Owner team is lead by a Chief Product Owner (CPO).  The CPO may be a PO on a delivery team, this is common on small programs, although for larger programs the responsibility of leading the Product Owner team will prove to be full time work.  In organizations with a strong Product Management culture, the Chief Product Owner may be a senior Product Manager.

This team is responsible for requirements management activities within the program.  This includes:

1. Identifying the initial scope of the program.  The PO team will perform just enough initial requirements modelling, with active stakeholder participation where possible, to identify the initial scope of the program.  This scope is very likely to evolve over time, but for now the goal is to explore the scope sufficiently to get the program headed in the right direction.  See the process goal Explore Initial Scope for more details.
2. Ongoing requirements elicitation.  A primary job responsibility of anyone in the Product Owner role is to elicit and explore stakeholder requirements.  In the case of a program the entire PO team must coordinate their requirements elicitation efforts.
3. Assigning requirements to sub teams.  As new requirements are identified the PO team will collaborate to identify the appropriate sub team to perform the work and then assign the work to that team.
4. Managing requirements dependencies.  There are always dependencies between requirements, and these dependencies should be managed by the appropriate Product Owners.  For example, if a requirement (R1) assigned to sub team A depends on a requirement (R2) assigned to sub team B then ideally R2 should be implemented either before or at the same time as R1.  Otherwise the people implementing R1 will need to mock/stub out the missing functionality until it becomes available.  Read Managing Requirements Dependencies Between Agile Teams  for more details.
5. Developing a product roadmap.  The PO team is responsible for developing a product roadmap for the program which lays out a high-level business direction for the product. This roadmap should reflect your organization’s overall business roadmap, if you have one.

The Product Owner team will meet as often as they need to.  We’ve seen some PO teams meet on a daily basis for 30 minutes each to manage requirements between sub teams.  We’ve also seen PO teams that meet weekly for two hours to do this work.  The important thing is that they self organize to determine what works best for them.

The Product Owner team may include business analysts (an example of a specialist role in DAD) who supports the POs in working with stakeholders to understand their requirements.  This is particularly important whenever the team is addressing significant domain complexity or whenever stakeholders are geographically dispersed.

Tailoring Considerations

In medium-sized enterprises this Product Owner team approach may be applied to your entire IT department.  In this case the focus of the PO team is that of your entire portfolio of ongoing IT solution delivery efforts and not just a single program of interdependent teams.

In large enterprises the Product Owner team for a program may be part of a larger Product Management team for the entire organization.  More on this in a future blog posting.

One of the key philosophies of the Disciplined Agile (DA) toolkit is that it presents software development teams with choices and guides them through making the right choices given the situation they face.  In other words, it helps them to truly own their process.  Part of doing so is to choose the software delivery lifecycle (SDLC) that is the best fit for their context.  In this blog posting we overview the DAD Exploratory lifecycle which is based in part on Lean Startup strategies.

This lifecycle can be applied in two ways:

1. As a replacement of the Inception phase of other lifecycles.  In the Inception phase we invest a short yet sufficient amount of time and effort to validate that the initiative being considered makes sense and to gain agreement on the stakeholders’ vision.  In a situation where the actual need and value of what is being proposed is in question this approach is a very good way to determine the true market need before scaling up the initiative and moving into the Construction phase.
2. As the implementation approach in the Construction phase.  After applying the Exploratory approach to validate your vision, a decision needs to be made regarding which of the four DAD lifecycles to apply as we move into Construction. For instance, you may choose to use DAD’s Scrum-based basic agile lifecycle if there is sufficient confidence from the learnings in the Inception phase regarding the viability of the vision.  However, if there remains some uncertainty regarding the feature set to be delivered it may make more sense to continue using the Exploratory lifecycle to build out the product in Construction.

The following diagram overviews the DAD Exploratory lifecycle.  This lifecycle is followed by agile or lean teams that find themselves in startup or research situations where their stakeholders have an idea for a new product but they do yet understand what is actually needed by their user base.  As a result they need to quickly explore what the market wants via a series of quick learning experiments.

Now let’s describe how the Exploratory lifecycle works.  There are six activities to this lifecycle:

1. Envision.  Your team will explore the idea and identify a potential implementation strategy for implementing it.  This could be as simple as getting a few people together in a room to model storm both the business vision and your technical options on whiteboard and paper.  You want to do just enough thinking to identify a viable hypothesis for what your customers actually want.  This hypothesis needs to be testable, which implies that you need to identify how you are going to measure the effectiveness of the new functionality that you produce.
2. Build a little.  Your team should invest just enough effort to build a solution that tests the hypothesis.  In lean parlance you want to build what’s known as a minimally viable product (MVP).  The amount of effort will vary, from several days to several weeks – your goal is to make something available very quickly so that you can test your hypothesis.
3. Deploy.  Once your current solution is ready it is deployed into an environment where you can test your hypothesis. This deployment may be to a subset of your customers, in many ways what used to be called an “alpha” or “beta” release, so that you can determine whether the solution is of interest to them.
4. Observe & measure.  Once the solution is available in production you want to determine what aspects of it, if any, are of interest to your user base.  To do this you will need to instrument your solution so that it logs data regarding important events within it.  For example, you may decide to record when a screen/page is accessed, when a sale occurs, when certain business functions are invoked, and so on.  The idea is that you want to understand which functionality end users find useful, which functionality leads to customer retention, which functionality leads to greater sales, … whatever is important to you.  Generation of this data enables you to monitor, to observe and measure, how well the new functionality is received by your user base.  This in turn allows you to make a fact-based go-forward decision.  If the functionality is well received then you may choose to continue with the existing strategy and add more functionality.  Or your strategy may be so successful that you decide that you’re ready to productize the development of this solution. If the functionality wasn’t well received your team might choose to pivot and continue in another direction or even give up completely.
5. Cancel.  Sometimes you discover that the product idea isn’t going to work out after all.  In fact, this is particularly common in research and development (R&D) environments as well as start ups.  The advantage is that if an idea is going to fail, then it is better that you learn that it’s a failure quickly so that you can devote your energies into other strategies.
6. Productize.  After several iterations of building a little, deploying, and then observing & measuring that you’ve identifying a product that will be successful in the marketplace (or in the case of internal application development successful with your user base).  As described above, although you may choose to continue following this lifecycle, a common decision is for the team to adopt one of the other DAD lifecycles – such as the Scrum-based agile lifecycle, the Kanban-based Lean lifecycle, or the Continuous Delivery lifecycle – and effectively treat the time they spent following this lifecycle as their Inception phase.

To summarize, the DAD process framework takes a flexible, non-prescriptive approach to software-based solution delivery.  As a result of this philosophy DAD supports several development lifecycles, one of which is the Lean-Startup-based Exploratory lifecycle described in this posting.  This lifecycle is typically followed in situations where you are unsure of what your user base wants, and sometimes even when you are unsure of who your user base (your customers) will even be.

We have just published a Disciplined Agile Manifesto, an extension to the original Agile Manifesto.

Why have we done this? Since 2001 we’ve applied the ideas captured in the Agile Manifesto and have learned from our experiences doing so.  What we’ve learned has motivated us to suggest changes to the manifesto to reflect the enterprise situations in which we have applied agile and lean strategies.  Because the original authors of the Agile Manifesto have made it clear that they intend to keep their Manifesto static we have decided to move forward on our own with this extension.

We believe that the changes we’re suggesting are straightforward:

1. Where the original manifesto focused on software development, a term which too many people have understood to mean only software development, the DA toolkit suggests that we should focus on solution delivery.  In short, we prefer solutions over software.
2. Where the original focused on customers, a word that for too many people appears to imply only end users, the DA toolkit suggests that it focus on the full range of stakeholders instead.  We prefer stakeholders over customers.
3. Where the original manifesto talked about projects, we believe it is more accurate to talk about teams.  As a result we replaced the word project with team throughout the principles.
4. Where the original manifesto focused on development teams, the DA toolkit suggests that the overall IT ecosystem and its improvement be explicitly taken into consideration.
5. The original manifesto focused on the understanding of, and observations about, software development at the time.  Since then there has been some very interesting work done within the lean community since then (and to be fair there was very interesting work done within that community long before the Agile Manifesto was written).  This manifesto incorporates lean principles, in particular considering the whole, visualizing workflow, and minimizing work in progress (WIP).

For earlier versions of the Disciplined Agile Manifesto, see Reworking the Agile Manifesto on IBM Developerworks and the book Choose Your WoW!

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).

Retrospectives are a great way for teams to explore potential improvements to the way that they work.  A team will get together, discuss what is working well for them, what is not working so well, and hopefully identify ways that they could improve.  It’s this last activity that can be challenging.  You may know that your team is facing a problem but you might not understand your options.  For example, perhaps your team is struggling with the way that it is being funded.  The current funding mechanism is to estimate the cost up front and then allocate these funds to your team.  This motivates your team to be wary of changing requirements due to the fear of going over budget, something that decreases your ability to produce a solution that meets the true needs of your stakeholders.  You have suggested to management several times that a time and materials (T&M) approach would be more appropriate, but you have gotten nowhere with that conversation.

This is where DAD’s process goal-driven approach can help out.  In this case the goal Secure Funding provides some insight.  The process goal diagram, see below, along with the supporting descriptions of each technique, their advantages and disadvantages, and advice for when the technique is applicable can help your team to understand their options and hopefully argue for a better funding strategy.  Although a T&M approach might not be palatable to your financial team right now, perhaps they would be willing to consider a stage gate approach to funding.  Or, perhaps they would be open to a T&M approach but they just don’t understand the tradeoffs between T&M and fixed cost.  With DAD’s goal-driven approach the team can arm itself with the arguments that it needs to have a knowledgeable conversation with the actual decision makers.

Of course this is just one example.  The DA toolkit addresses a range of goals pertinent to successful agile solution delivery, all of which can provide team’s insight into potential process improvement options.  Knowing your options is an easy way to up your game during retrospectives.