Disciplined Agile

The Agile manifesto is only 4 lines, there are only 12 principles for agile software and the original Scrum Guide was less than 20 pages, so how hard can Agile be?

Chess has only a couple of dozen basic moves so how hard can it be to get to checkmate?

How many times have you heard?

• All you need to be Agile is to get the team doing a few funky ceremonies

Or the approach to evolving a team from forming to performing:

• If the team isn’t performing after a month then the manager is not effective.

Despite the apparent simplicity of Agile, transforming to Agile is hard and the learning curve is very steep.  Depending on the team and the individuals, a transformation from waterfall to a high performing Agile team can take anywhere from 6 months to a year or more.  That’s not to say that they won’t be productive over that period of time.  In fact, they will start delivering business value at the end of the first iteration, but the team will be in constant growth and development over that period of time because not only do the people have to learn a new process, they also need to learn a new way of thinking as well as a new way of working as a team.

1.0 A new process

Aside from being excited to work with the thought leaders in the agile world, the reason I joined with SA+A is because of the Discipline Agile Delivery (DAD) decision framework and the way it captured all the tough stuff that I had been wrestling with for years.  With many years of experience building agile teams, I considered myself somewhat of an expert with answers to a lot of the difficult questions.  When I reviewed DAD I realized that the answers I had gained from my own personal experience would not apply in all circumstances or for all teams.  Context counts.  The DAD Agile/Basic and Lean/Advanced project lifecycles have three phases: inception, construction and transition.  Each phase has a collection of process goals, and each goal encompasses several process decision points.  And, each decision point has a collection of options to choose from.  These process goals, decision points and options have been empirically assembled by analyzing many agile teams to see what makes an agile team successful.  This framework gives a team the ability to define a process that works for them.  Is this difficult to do?  Absolutely!  Defining a process to use is always difficult. BUT…..  The framework provides some guidance. Each goal option has default options that the team can use to get started and the options are listed in preference order so the team can easily pick an initial option.  As the team evolves and matures they can chose the more advanced options and evolve and mature their process.  Does the toolkit include all possible options?  Definitely not, but the options are certainly extensive.  The framework has evolved over time and continues to evolve as the coaches and thought leaders gain more experience and work with more diverse teams.

No matter which lifecycle the team has chosen to use; whether the team is using classic Scrum (Basic/Agile) or Kanban (Advanced/Lean) or a tailored process created using a toolkit such as DAD, the team is going to need practice and discipline to get it right.  That means, executing the lifecycle, doing periodic retrospectives, updating the process and then repeating again and again until they get it right.  Changing behaviors is hard and the team will struggle to be successful.

2.0 A new way of thinking

No matter how you cut it, transforming to Agile is a cultural change and culture changes are hard.  Not only is it hard for those who want to make the change but almost inevitably there will be pockets of resistance from people are happy with “the way we’ve always done it”.  Unfortunately, political infighting is the biggest risk to innovation. It is going to happen, you may as well brace yourself for it.

The roles are changing from traditional roles (such as: developer, business analyst (BA), system analyst (SA), quality assurance (QA) and project manager (PM), to new unfamiliar roles (such as: product owner (PO), team lead (TL), architecture owner (AO) and team member).  The traditional roles may be deeply embedded in your HR hiring and performance review processes. Transitioning to the new roles will require a realignment of skills and abilities that is bound to cause great consternation amongst the team members.  Often this is a very difficult transition for project managers, in particular, because they find that a lot of the traditional tasks (i.e. work breakdown structures, planning, estimating, etc.) are now the responsibility of the whole team.

The team needs to start thinking in smaller deliverable pieces.  The concept of delivering a complete system from known specifications at the beginning of the project has been the fallacy of traditional development.  The cost of delaying delivery to the very end of the project and the lack of ability to meet actual customer needs can be eliminated by delivering minimum functionality early and augmenting with new and improved functionality iteration after iteration in close collaboration with the end customer.  But moving to this model of continuously delivering can be a tough adjustment for developers.  Even (or maybe especially) for seasoned developers, the concept of starting to build and deliver not knowing all the detailed specifications up front can be very unsettling. Getting comfortable with this model takes time and experience before developers cease to fall back on old behaviors.

One of the pillars of agile is complete transparency with the business and the stakeholders into the team, the process they are using and the delivery of the business functionality.  With the business embedded in the team on a day to day basis and iteration reviews to demonstration and approve all the deliverables from each iteration, there is no hiding problems when they occur and no hiding late deliveries or failed iterations.  On the flip side, the business is there to celebrate the wins and recognize the deliveries at the end of each iterations and they are part of determining the velocity of the team and adjusting the schedule to match the velocity.

The new way of thinking also requires new tools.  Tools that can build dashboards to automate and display the development intelligence metrics that provide transparency into the team’s performance.  Tools that automate configuration management, continuous integration and continuous integration as well as automated testing.  All of these endeavors are hard and required skilled individuals to lead; none of these comes for free.

3. A new way of working with others

More people skills are required by everyone.  People are now going to be working much closer together physically and will be interacting and collaborating on a much more frequent basis.  Experience working together (often for many years) may give an advantage to some team members, however, they still need to learn how to work together as a team.

3.1 Team Development Phases

Tuckman’s team development model includes the phases: forming, storming, norming, and performing. These phases are all necessary and inevitable in order for the team to grow, to face up to challenges, to tackle problems, to find solutions, to plan work, and to deliver results.  The number of iterations required to move through the phases will vary by team depending on factors such as: company culture, skills, experience, familiarity with each other, leadership (or lack thereof), external influences and coaching etc. Teams may also plateau in a phase before entering the next phase.

Agile teams will go through the four Tuckman phases:

1. Forming. All teams will go through the forming phase. Typically this take 4 to 6 iterations for the team to: understand the lifecycle process, understand how to work together, understand what the team goal is, and most importantly to get comfortable enough with each other to risk the possibility of conflict.  During this phase, the team’s velocity will vary considerably especially for the expected failed iterations although there should generally be a trend upward in the velocity.  Retrospectives in this phase tend to be very cordial and factual because everyone is avoiding conflict.
2. Storming. The storming phase can be very upsetting to both the team members and team managers. Often managers will step in to solve the storming issues without realizing that it is a necessary phase for the team to work through on their own.  Conflict, disagreements and personality clashes must get resolved before the team can move to the next phase.  Unfortunately, this phase is a make or break phase and it is hard to predict just how many iterations it will take but it is not usual to expect 3 or 4 pretty rough iterations.  Some teams will completely disintegrate during this phase and it is certainly not unusual to have a decrease in velocity during this phase.  Some members of the team may find they have basic incompatibilities and need to move to another team and this change in team membership can revert the team back to the forming phase.  The retrospectives tend to be very interesting and intense during this phase as they deal with the inter-personal issues of the team.  You can pretty much expect that there are going to be some hurt feelings no matter how safe an environment you have.
3. Norming. The norming phase is when the team comes back together stronger and more cohesive for having weathered the storming phase. They have resolved their issues and have developed a new synergy where the team just “works well together” and it is fun to be part of the team. The team velocity should trend upward and then level off as the team hits its capacity consistently.  With the new-found synergy of the team, the retrospectives can focus on process improvement and optimizing the operation of the team with the hope of transitioning to the performing phase.
4. Performing. The performing phase is the goal for all teams but very few actually get to this phase. Not all teams can get to the high level of performance of a Special Ops team where each member knows exactly what their team mates are doing and what they need to do to work as a cohesive unit.  A team in performing phase no longer needs a coach or supervision but can operate autonomously and efficiently.

3.2 Team changes everything

With self-organizing teams, decisions are now made at the team level rather than at the PM or manager levels.  This can be a difficult transition for both the team members and the managers.  Team members are often use to others making the decisions for them and wait for decisions or are reluctant to make decisions.  Managers often feel disempowered when decisions are no longer in their hands because the decisions are made by the team.

The team still has the responsibility to do the traditional activities such as; analysis, design, development testing and deployment.  However, under the new model, the team also takes on the inception responsibilities of: developing user stories, sizing the stories, estimating the stories, creating the product and architectural vision, and developing the release plan.   During construction the team also has to: plan the iteration, do look ahead planning, and have an iteration review (i.e. demo) with the stakeholders.  To keep the team working together they need to have the daily coordination meeting (i.e. Scrum) and to keep the team growing and evolving of course they need to do the retrospective at the end of each iteration.

Thinking, analyzing, planning and building just-in-time is a new way of thinking for a traditional team.  The inception phase in particular can be a difficult adjustment.  Designers and developers are used to doing all the analysis and design upfront.  Doing just enough analysis to be confident of a solution and then writing the user stories to do the work and build the plan is a difficult transition.  Writing user stories so they can get started and learn as they go is a very difficult transition.  Building just the simplest framework and then adding required features and functionality as needed requires practice, training and reinforcement.

There is much more focus on delivering quality because the team is responsible for development, delivery as well as product support.

4.0 The Bottom Line

Chess has only a couple of dozen basic moves and so it is simple to learn the basics.  However, after 3 moves there can be several billion moves available making it so complex that it can take a lifetime to master.  Transforming to Agile is a lot like that.  It looks very simple on the surface but under the covers it can get very complex very quickly.  That’s where the value of a good coach comes in.  You need a coach who brings a lot of experience to the table who will be open and honest with you about what needs to be done and how to get a successful transformation.

What is the point of the retrospective?

The retrospective is one of the most important ceremonies in all of agile.  This is the time the team spends together to assess how they are working together and define steps to improve that process.  It needs to be a “safe place” where people are able to speak openly and honestly.  This is their opportunity to air their dirty laundry and work through their inter-personal issues.  This is a time of growth for the team and for the team to take ownership of improvement.  The team lead will facilitating the retrospective and should manage the interactions to keep the environment safe.

Define the Team

If the retrospective is a team ceremony, then what do we mean by team?   The team includes: the team lead, the architecture owner and all other members that actively contributed to meeting the deliverables for the iteration.  This includes: developers, testers, BAs, QAs, or other specialists such as technical writers, database engineers etc.

What about the Product Owner (PO)?

The PO is NOT a member of the team.  They certainly interact with the team but they do not contribute to meeting the deliverables for the iteration so they are not a member of the team.  They are not allowed to participate in the planning poker for the user stories for the same reason.  The team votes because they are on the hook for delivering based on the sizing and the estimates but the PO is not on the hook, so they don’t get a vote.

Should the Product Owner participate in the retrospective?

In general, I would start by including the PO in the retrospectives because the team does have to learn and adjust to working with the PO. Keep in mind though that the PO may come and go but the team should stay together so it is most important that the team works well together.??As a coach, I usually talk to the PO beforehand to say that they are an invited guest and that it is a privilege to be part of the meeting so they should act accordingly.   I have been in many situations where the PO was welcomed at the retrospective, and felt left out if not included.  I favor building trust between the business (the PO is their representative) and IT (the team).  Including the PO in the retrospective can help the PO assimilate with the team.

I have also had several situations where as the coach I had to ban the PO from the retrospective because they were too commanding and disruptive in the meeting for the team to have an effective retrospective.  I have also seen many situations where the PO is also the resource manager of members of the team (which in itself is not recommended).  Having managers in the room can definitely have a dampening effect on the member’s willingness to be open and honest about problems and solutions.

If the PO doesn’t participate, at least as an observer, the team runs the risk of having to “sell” the cost of their improvement actions (against other backlog items) after coming up with them. Hopefully the PO is engaged enough with the team to understand its weaknesses and support improvement in those areas whether then attend the meetings or not.

Team Decision

Retrospectives are about improving the process, and a non-trivial part of that is optimization of collaboration between the PO and the team.  I would suggest that the team should decide whether or not to include the Product owner.

What about the Stakeholders?

The retrospective should absolutely be a closed door session for the stakeholders since the retrospective must be a “safe space”.

There was a twitter debate lately that talked about a team being subjected to “a drive by criticism from 2 PM’s during a Retrospective”.  This is a good reminder why we constrain attendance.  The “safe place” is affected by the presence of people with positional authority, potential agendas or other implicit impact.??The team may decide to invite such people – usually to ensure that they are communicating improvements needed that are beyond their locus of control.??Having outsiders as guests at the retrospective will change the dynamics but at least it is a team decision to do so.

It is very important that the team own their process.  If they’re uncomfortable that someone is in the room then that person should be asked to either change their behavior or leave (perhaps to be invited back in the future).??The coach should always be thinking along the lines of “do we have the right people in the room” and then act accordingly

Isn’t agile all about transparency?

There was a twitter debate lately that centered on transparency.  I believe that transparency is a key element to making agile successful.   I’m all for transparency in everything about agile; EXCEPT the retrospective!??Sometimes you need to have a family meeting outside of the public eye and that is the retrospective. The retrospective is all about resolving your issues in private so that you can present a united front to the rest of the world. To use a sports analogy, an NHL coach doesn’t invite the business (fans) into the dressing room between periods.  There are lots of other places for transparency; the retrospective doesn’t have to be one of them.

The output of the Retrospective

While the actual retrospective meeting is closed to other observers, I would suggest that the action items coming out of the retrospective need to be made public and posted as an information radiator for everyone to see.  The changes are more likely to get implemented if the team sees them every day.  The team may also want to “radiate” their improvement actions on their dashboard.

The actions and results of the actions may also be shared with other teams through what is often called a Retrospective of Retrospectives. I encourage teams to only choose one or two areas for improvement at a time to provide focus and make meaningful progress.

As mentioned in a previous post on Team Member Rights, transforming to Agile is a culture change, and all cultures have rules so that everyone understands their expected behavior. DAD has inherited some of the basic rules from the XP world. Each time I present these rules in the training course, inevitably they end up on the list of things that “freaked us out”. That means to me that the rules are really important and that the community needs to be talking about them and getting a clear understanding and acceptance.

The Responsibilities of Everyone:

1. To produce a solution that meets the needs of stakeholders given the resource constraints. The primary goal of the team is to meet the stakeholder needs as best they can.
2. To optimize the use of those resources. Optimizing the resources should be looked at from a long term perspective. Tasking the specialist on the team with a particular type of task may seem optimal in the short term because the task is done quickly. In the long term it may be more optimal to assign a new team member to train with the specialist to do that type of task even if it takes longer to complete the current task.
3. To be willing to collaborate extensively within your team including those outside your specialty. Gone are the days when a developer could go hide in a corner and hack away at code. Collaboration is required across all team members.
4. To share all information including “work in progress”. One of the keys to successful Agile is transparency. If you run into a problem, tell the team so they can help out or at least re-plan. If you complete something quickly, tell the team so they can work on next steps whether that be: testing, or documenting or promoting. Everyone should know what everyone on the team is doing all the time.
5. To coach others in your skills and experience. The goal is to increase the skill set of everyone on the team so be prepared to teach your skills to the other team members. Previously the performance of people was assessed on their ability to perform specialty tasks. The focus needs to shift to how well a person collaborates, shares and increases the teams ability to perform.
6. To expand your knowledge and skills outside your specialty. Again, the goal is to increase the skill set of everyone including you so everyone needs to be open to learning new skills so they can help the team do every required task.
7. To validate your work as early as possible, working with others to do so. No more writing code and getting it promoted directly to production or producing documents that haven’t been reviewed. All code should be reviewed by another developer; non-solo development is great for this because it reduces the feedback loop to almost zero since 2 sets of eyes are always on the code. And all code needs to be tested against the acceptance criteria in the user story. Nothing goes out without someone else on the team reviewing it because it is a team responsibility to ensure quality.
8. To attend co-ordination meetings in person or through other means if not collocated. The co-ordination meeting is the most important meeting of the day and nothing else takes priority. Get to the meeting and get there on time. If you are late then you are holding up the whole team.
9. To proactively look for ways to improve team performance. The retrospectives are designed to fix and improve the team’s process. Come prepared to the meeting to discuss how the iteration went and talk about things that went wrong and how to fix them. However, if you see something during the iteration that can be fixed, don’t wait for the retrospective!! Bring it up at the co-ordination meeting and suggest a fix right away.
10. To avoid accepting work outside of the current iteration without consent from the team. The team commits to complete a specific bundle of work when they start an iteration. That means that all team members have made a commitment to complete all the work in the iteration. If you as a team member take on work from outside the iteration (whether it be from a colleague or an old boss or your current boss) then it means you are not working on tasks for the iteration and you are letting your team down. You should refuse all outside requests for your time. If that doesn’t work tell them they need to talk to the team lead. The team lead should refuse the request. If that doesn’t work then tell them to talk to the Product Owner. The Product Owner should refuse the request but offer to write it up as a user story and put it onto the backlog for consideration.

Transforming to Agile is a culture change and all cultures have rules so that everyone understands their expected behavior. Disciplined Agile (DA) has inherited some of the basic rules from the XP world. Each time I present these rules in the training course, inevitably they end up on the list of things that “freaked us out”. That means to me that the rules are really important and that the community needs to be talking about them and getting a clear understanding and acceptance.

Let me first address The Rights of Everyone:

1. To be treated with respect. Whether you are going Agile or not, this is a good thing to promote. Let people be heard, don’t talk over people, listen to what they have to say, no name calling etc etc. Every one of your team mates brings something of value to the team so show them the respect you expect in return.
2. To work in a “safe environment”. This goes hand in hand with treating people with respect. Everyone needs to feel they are in a safe environment, that they can offer input without being mocked or ridiculed. For everyone to freely collaborate they need to know that their input is valued.
3. To produce and receive quality work based upon agreed standards. Establish the work standards up front. Make sure everyone on the team understands the standards and agrees to the standards. No one can be expected to meet moving standards.
4. To own the estimation process. The people doing the work get to do the estimations so that estimations are not being imposed on the team
5. To determine how teams resources are allocated. The team has the right to determine who is going to work on what task when. The team knows the strengths and weaknesses of the team better than anyone else so they know best, how to meet the team goals
6. To be provided good faith information and decisions in timely manner. For the team to be effective they need good information to work with and information must be available when they need it. Any delays in providing requirements or answers to questions will reduce team productivity.
7. To own the team’s processes and be enabled to improve them. DA recommends an initial process but as the team matures the team has the right to adjust and improve the process so that it works for them. The whole point of doing retrospectives is to have the team reflect on how well the last iteration was performed, keep doing the activities that worked and fix the activities that didn’t.

See the post Responsibilities of Everyone where I discuss the other side of the coin and look at responsibilities that pay for these rights.

Along with the new look and feel we have a new email digest to keep everyone in the community up to date with the latest posts and comments.

Come and be part of the community. Learn about the new and exciting ideas being discussed and share your ideas. Sharing and collaborating makes everyone stronger!!

Please invite your Agile colleagues to join and be part of the community.