Disciplined Agile

Right from the outset, agile teams are expected to self-organize. Let’s take a team that just started practicing Scrum. To do Scrum well, they must self-organize how they plan the next two weeks’ worth of work during the iteration planning. They must self-organize how to coordinate today’s work during their standups. They must also self-organize how to solicit feedback on what they built (iteration demo) and how they built it (iteration retrospective). On top of that is the matter of actually self-organizing the work of building the actual solution they are working towards. 

That is a lot to ask any team, especially one that is newly formed, or one that has recently changed from their old way of working (WoW) to an agile WoW. I, for one, would venture that it is impossible. A newly formed team, or a team that recently changed WoW, have to normalize first before they can carry out those tasks in a self-organizing manner.

The fact that Scrum and other agile ways of working expect this from the outset is what I call the fallacy of instant self-organization.

What is team development?

Team development and team building often get mixed up. Let’s be clear, team development is not team building. Rather, team building can be a part of team development. Team building is a catch-all phrase for activities where colleagues get to know each other better as fellow humans, not just people at work. Team building can be anything from quick social games (like Pecha Kucha or two truths and a lie) or getting away from the office for a celebratory meal, drink or game of bowling.

Team development on the other hand is a deliberate process in which a team takes time to explore its potential; how it can become even greater than it’s been before. Team development is a journey.

What is a team development model?

There are plenty of team development models to pick from. How teams form and develop has been the fascination and research of many people.

Before we move on, let’s recall the wise aphorism by George Box: that “all models are wrong, but some are useful.” Models are like a pair of spectacles. They help us see the world with more clarity to make better sense of it. But they are all inherently “wrong” because they are not the world itself.

That said, models can be very useful and provide insight and guidance for our world of agile teams. As an agile practitioner, I find three models useful: Bruce Tuckman’s stages of team development model, the Drexler/Sibbet team performance model, and Patrick Lencioni’s five beaviors model.

What can we learn from team development models when it comes to self-organization?

Looking across all three models, we can extract some key points about team development.

First, there are no shortcuts to high performance. In all the models, the team has to travel a journey of set steps or stages before reaching high performance. The steps start out very basic, like building trust and getting to know each other, and progresses to something more advanced where we learn to solve work tasks together. This all seems like a given, but it is often overlooked or forgotten.

Secondly, even though the models all lay out the road to high performance as a neat step-by-step journey, the journey is not linear. We are dealing with people, not printers. People and their interactions are messy, complex and to a large degree unpredictable.

Thirdly, regression can happen anytime. As I discussed above, the scenario of a team that has recently changed their WoW is a prime example of team development regression. The abrupt change of their way of working (say, from a traditional approach to an agile WoW) can likely cause the team members to be unsure of their role on the team, how they are supposed to work together now, and can even erode some of the trust inside the team. Regression can also occur when team members come and go, and in the case of significant external changes, regression is always something to be on the lookout for, and it is always a question that leaders should ask themselves when they make changes. Can this change adversely impact the team’s journey to high performance?

The last and most important point seen from an agile practitioner’s perspective is that the models all offer guidance for the team’s journey. Take the Drexler/Sibbet model for example:

Source: http://www.robertmcneil.com/2016/02/12/the-drexler-sibbet-team-performance-model/

Not only does it tell you what’s going on in each stage (by naming the stage intuitively), it also describes how to move to the next step. If you look closely at the first step (Orientation: why am I here?), you see that if left unresolved, you will get patterns (or rather anti-patterns) of: disorientation, uncertainty, and fear. The tools that we as team leaders have to resolve this step and help the team onwards are: providing purpose, team identity and membership.

Continue your learning journey

The Disciplined Agile People Management process blade contains an overview of how to manage people in an agile enterprise.

The Disciplined Agile Grow Team Members process goal contains a collection of tools and practices of how to continuously grow our team members.

So much of agile teams’ successes depend on collaborative decision-making. Take for example refining the backlog. That is a collaborative decision-making process where the development team, the architecture owner, and the product owner choose the relevant details of each user story. The retrospective is another collaborative undertaking where the team explores and decides how to improve their way of working. Solution modelling, user story estimation, story mapping, and big room planning are more examples of similar processes. The list goes on and on.

If decision-making should be truly collaborative during these processes, how can we encourage everyone to contribute? What can we do to make this work?

First, we need a model that gives us an overview of how group decision-making works. Sam Kaner’s dynamics of group decision-making is a great starting place. The model is split into three parts.

Source: “Facilitator’s Guide to Participatory Decision-Making” by Sam Kaner (2007)

Part 1: In the beginning, all ideas are welcome during divergent conversations. We begin with a question or unsolved challenge. As we explore the topic, we easily get to familiar options and opinions. The tricky part is moving past the familiar and uncovering new and fresh perspectives and ideas.

Part 2: Then, with a suite of diverse perspectives and options we enter the groan zone. That is exactly what it sounds like: uncomfortable, awkward, and seemingly dysfunctional. Questions arise. How do we move on? What’s the best idea? Are we stuck? This is the uncomfortable space of moving from “now-we-have-all-these-great-ideas” to, “how-do-we-decide-which-one-to-move-forward-with?” Misunderstanding and miscommunication are normal, natural aspects of the collaborative process. The groan zone is a healthy, unavoidable consequence of the diversity that exists in any group.

Part 3: Eventually, we steer towards the finish line in the convergent stage. This is where we condense the large number of ideas and options to one final decision that we move forward with.

Divergent thinking: ways to keep an open mind

Source: “Facilitator’s Guide to Participatory Decision-Making” by Sam Kaner (2007)

The parachute mind (it works best when open)
When starting the divergent stage, think of parachutes. They work best when fully open. The same goes for our minds in the stage of the process which can be easier said than done. Below are some practices that will help you keep your ‘parachute’ open.

Cognitive empathy
Cognitive empathy is the ability to empathize with how others on your team think. Approaching divergent thinking by embracing the fact that we all think differently and that there is no right or wrong way to think about the problem we are solving is a big step in the direction of keeping an open mind. There are a number of short games that illustrate cognitive empathy. One of them is “this is not a stick”.

This is not a stick
To play “this is not a stick” game you need a stick (or something similar, like a broom shaft) and a group of people (between 3-8). Someone starts the game by performing an action with the stick, say pretending to throw a javelin, and says: “this is not a stick, this is a ______”. The other people in the group then has to guess what the stick is. When someone guesses “javelin”, the stick is handed to the next person in the circle and they perform a new action, say, pretending to be fishing, while saying: “this is not a stick, this is a _______”. Playing the game for 8-10 minutes typically allows everyone to go at least twice.

Not only does the “this is a not a stick” game underline the importance of cognitive empathy, it also shows how the group the natural progression in the divergent stage of first coming across familiar options, like javelin and fishing pole, only to move to newer, more diverse perspectives when you build on each other’s ideas.

Yes, and!
Speaking of building off each other’s ideas, the “yes, and!” mindset is a great way to do that. This technique is borrowed from improv theatre where the performers continue each other’s sentences by saying: “yes, and!” The opposite of “yes, and!” is either “no!” (as in, that idea will never work) or the more subversive: “yes, but”. Saying “yes, but” means you cancel out whatever was said before the but and replace it with your own idea or opinion. Take the example of your co-worker, Bob, who presents his idea of selling yellow t-shirts. You know this will never work, so you start your sentence with: “Yes, I like that idea, but we know our customers prefer blue t-shirts”. You have effectively closed down Bob’s idea and replaced it with your own. That is the opposite of a parachute mind.

Using “yes, and!” a different response could be: “Yes, I like the idea of yellow t-shirts, and we can bundle them at a discounted price with our popular blue t-shirts to test the market’s appetite for yellow shirts.”

50 bad ideas
This last technique seems odd at first, and it can really help your team if they are stuck at the “familiar options” state in divergent thinking. Sometimes, you need sheer volume to move on to the newer, more diverse perspectives. Setting yourselves the goal of coming up with “50 bad ideas” can allow you to consider more ideas and move forward.

It works by writing down 50 bad ideas on individual post-it notes. Often it doesn’t take more than 5-7 minutes and it can loosen up the group with some laughs. When done, the group is often energized and has opened up their horizon and can move on to brainstorming newer, more diverse perspectives related to the challenge you are solving.

The groan zone: ways to grit it out

Source: “Facilitator’s Guide to Participatory Decision-Making” by Sam Kaner (2007)

In the groan zone, you can use several practices from divergent thinking as well: the parachute mind, cognitive empathy, and “yes, and!” In addition to those practices, there are a number of techniques to help you grit your way through the groan zone.

Active listening
There are three ways to listen: listening to yourself (“I feel like pizza tonight”), listening to others (“I see…”), and listening to others and taking their context into perspective (“It’s okay. I know you were just trying to help”).

Source: http://www.mtbunnies.com/

To move successfully through the groan zone and safely make it to the convergent stage, we need to do our best to stay at level 2, and ideally at level 3.

Emotional intelligence
This state is often uncomfortable, awkward, and seemingly dysfunctional. Questions arise and doubt starts to creep in. How do we move on? How do we find the best idea? Can we even agree on what’s best? Just like misunderstanding and miscommunication are normal aspects of the collaborative process, so are our emotions.

The key is not to ignore and suppress the emotions as they arise in the group, but to deal with them in an intelligent way. So how do we do that?

Source: “Working with Emotional Intelligence” by Daniel Goleman (1998)
Image source: https://positivepsychology.com/emotional-intelligence-frameworks/

Daniel Goleman’s competency framework can help us navigate how to deal with emotions in an intelligent way -as they arise inside ourselves, and as they arise inside the group. It starts with emotional self-awareness and self-management. Once we have dealt with our own emotions, we can focus on the emotions in the group setting (social awareness) and then manage the group emotions in an intelligent way (relationship management), safely guiding us to the last stage.

Convergent thinking: ways to get to the decision

Source: “Facilitator’s Guide to Participatory Decision-Making” by Sam Kaner (2007)

We are almost there. So close to the finish line. To get there we need a way to ‘boil down’ our great ideas discussed in the groan zone.

Clustering ideas
Clustering is a really simple way of narrowing down your ideas and options. The technique is exactly what it sounds like: you cluster together the sticky-notes with similar ideas and then give that group a meaningful name.

Some teams prefer to cluster ideas in silence to avoid influencing each other (group think bias). Others prefer to cluster in collaboration and conversation. The choice is yours. Experiment and use what works for your team.

Plotting ideas
Plotting ideas allows you to rank your ideas based on dimensions that are important to your team and context. Let’s say you create a 2x2 grid with these dimensions: “alignment with our team mission (low/high)” and “implementation effort (low/high).” When you plot your ideas into that grid, it will quickly become apparent which ones are highly aligned to your team mission and are low-effort to implement. These are the ideas you pursue first.

Again, some teams prefer to plot the ideas in silence to avoid influencing each other (group think bias), while others prefer to plot in collaboration and conversation. The choice is yours. Experiment and use what works for your team.

Dot voting
The final technique is called dot voting.

Dot voting is a way to ensure that everyone on the team has a say in the final decision. By giving all the team members three votes (represented by three sticky dots) and asking them to place them on the three ideas they most like, we create a fair, transparent, and balanced way of getting to the final decision. If you have a lot of similar ideas, dot voting works even better when you cluster the ideas first.

Dot voting is always done in silence. When finished, one team member tallies the scores, and you can move forward with the winning idea.

Terraforming is the act of making an environment suitable for human habitation.  Terraforming has been popularized in science fiction as the act of evolving a planetary ecosystem, but in our context terraforming is the act of evolving your team’s physical workspace to make it more habitable for you to work.  Doing so in an important enabler for improving your way of working (WoW).

The Evolve Way of Working (WoW) process goal, the diagram for which is shown in Figure 1, involves several decision points that are pertinent to terraforming. In Disciplined Agile (DA) our philosophy is that teams should choose and evolve their WoW over time as they learn, and an important aspect of doing so is to recognize that you should be able to evolve your physical as well as virtual workspace.

Figure 1. The Evolve Way of Working (WoW) process goal diagram (click to expand).

As you’d expect, you have choices available to you.  In Figure 1 there are three decision points relevant to terraforming:

1. Organize Physical Environment. There are many options for organizing your physical environment.  A key issue is that you want people to be as close to one another as possible – the further away you are from someone the less likely you are to interact with one another, and the harder it becomes to share ideas and information. Ideally you want your team to have its own work room or at least be in a common open area together.  Having said that, it’s still useful to have “caves” or separate collaboration areas where people can escape to as needed to focus their efforts.
2. Choose Communication Styles. Some people are leery of work rooms or common workspaces because they’re afraid that they won’t be able to concentrate due to the noise.  There has in fact been numerous studies that show that productivity drops when people are forced to work in open work areas or worse yet “hoteling” desks.  Yes, this is definitely a problem.  However, it is vitally important to differentiate between the noise generated by people who aren’t working on your team and the information/discussions generated by those who are. In short, I want to hear what my fellow teammates are saying but not what the stranger beside me is. When your office is organized in an “open” manner we’ve found that you should strive to have everyone on your team is sitting together.  Furthermore, erect sound barriers (such as sound-proof whiteboards or moveable walls) between you and the other teams near by to provide further focus.  And speaking about whiteboards, you can never have too many.
3. Choose Collaboration Styles. The more flexible your physical workspace the greater your ability to collaborate with one another in an effective manner.

We’ve found that a great strategy for a company is to make physical things such as furniture and whiteboards readily available to teams.  Something as simple as a room full of (currently) unused furniture that a team can simply take from, or contribute things they’re no longer using into, goes a long way to providing flexibility.  And of course allowing teams to buy what they need, when they need it, is also crucial.  Smart organizations realize thatone of the best investments they’ll ever make is to spend a few thousand dollars on furniture and whiteboards to enable a team of people earning five or six figure annual incomes to improve their WoW.

Ideas for this blog was adapted from the book Choose Your WoW! This book is a handbook overviewing hundreds of agnostic techniques and strategies that agile and lean teams may decide to experiment with to see how well they work in the situation that they face.

In my experience in running dozens of process tailoring workshops, over several years, with of teams of every shape size and experience level and in different organizations, the most recurring comment is that the workshops “revealed all kinds of options we didn’t even realize were options!”   Although almost always a bit of a hard sell at the outset, I have yet to work with a team unable to quickly grasp and appreciate the value of these activities.

I had to do quite a bit of experimenting in order to get the timing and content of the workshops right – and learned over time that success is also predicated on knowing whom to include when. My first attempts were gruelling, close-to-full day affairs with entire teams in attendance, held at or close to project kickoff. Though transparent and inclusive, to my surprise this approach was actually deemed a waste of their time by many team members, especially those whose contribution would occur primarily in the construction phase. First lesson learned – A technical team lead, architect or senior developer can actually stand in for most of the developers in the early stages. I find it helpful to always bear in mind what George Dinwiddie (http://www.velocitypartners.net/blog/2014/02/11/the-3-amigos-in-agile-teams/) dubbed “the 3 amigos” in determining who needs to attend a process tailoring session. Be it at inception, construction, or even in transition, you need to tailor not only the processes, but also the attendance of the workshop in order to ensure you have the right mix of people, with the right collaborative mindset, to cover issues pertaining to 1) the business problem being addressed  2) the potential technical solutions to that business problem and 3) the processes (both team and organizational) that will enable the work to be carried out.

My second lesson learned pertained to the format and presentation of the process blades themselves. I found that simply working from the published process maps was insufficient, as we ran into onerous issues around how to best record the WoW choices teams were making. I eventually reproduced the entire process blade library in a spreadsheet format, with columns for comments. This seemingly innocuous administrative step quickly ushered in the third lesson learned – the sessions can be used not merely to document an immediate WoW decision, but also to identify future, more “mature” aspirational choices which the team can set as goals over a specified time period.

A fourth lesson learned, and one that was also enabled by using a simple spreadsheet tool, is that it became far easier to Align with Enterprise Direction. By “locking down” enterprise-level process choices across all the blades where applicable, a lot of potentially fruitless (at that point in time) discussion was saved for many a team. No use in discussing test automation strategies to death for instance in divisions still completely relying on manual tests, or at the opposite end of the spectrum, teams endowed with high-performing, well-integrated CI/CD environments. This is a large part of what DA calls self-organization within appropriate governance.

The fifth and final major lesson learned was to never start from a blank slate if at all possible. I would typically show up at a team’s first process tailoring workshop with a pre-filled version from another team facing somewhat similar challenges (the identifying data being scrubbed so they could not identify the previous team). I would then challenge the new team to reflect on the choices and determine whether they made sense for their own context. This also saved time and effort, as there are recurring themes and common challenges within organizations that all teams face.

Here’s an important note on determining participation – Ultimately, the teams themselves are the best arbiters of who should attend the sessions at varying stages of advancement. Allowing this will typically result in a bit of initial over participation, followed by under participation (especially is the pressure is on to get “real” work done!) – the key as facilitator is to coax the team back into balanced participation, and to lobby the organization for the necessary support in freeing people up. The support will become easier and easier to obtain as the benefits of allowing teams to choose their WoW become apparent.

Finally, be prepared for surprises. I once ran through the Program process blade with a team, only to have them come to the realization that … they weren’t really a Program! Which was actually a good thing as it helped avoid introducing a considerable amount of overhead, particularly in the area of program-level KPIs.

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.