This article originally appeared in the February 2013 edition of Web and PHP magazine and is republished with permission.

On Scrum projects, teams talk about delivering a working increment of functionality every sprint but what does this mean exactly?  Do teams need to deliver to a production environment every sprint?  This may work for maintenance projects, but what does this mean for new projects starting from scratch?  What kind of teams do you need to build increments of functionality every sprint?  In this article, we will discuss cross functional teams, increments of functionality and minimum feature sets.

One of the big challenges teams new to agile face is to understand the concept of vertical slicing of functionality.  It is a change in mindset that is challenging to adopt because coming from a waterfall world, teams may have a more sequential view of the development process.  Imagine you are trying to develop three pieces of functionality.  Figure 1 illustrates a typical horizontal slicing where you need to prepare the database and implement some architectural foundation before you can start delivering working functionality to the user.

Figure 1 – Horizontal teams working on features

Many companies adopting agile practices have development silos that exist around specialties.  For example, in a web company, you may have a team of integrators that work on the front-end side, developers that write server-side code and designers or architects that dream up the look and feel of the web site.

When making a transition to agile projects, the dependencies between these various teams will cause problems when attempting to deliver a complete piece of functionality inside a sprint.  The common mistakes these teams make are either:

• develop their pieces sequentially in different sprints and integrate later
• develop their parts in the same sprint as separate teams but fail to coordinate their efforts properly

Different teams developing pieces sequentially in different sprints makes it more difficult to understand when all the teams will complete their pieces of functionality and be ready to integrate and deliver them.  One team running late delivering their piece may impact the schedule of other teams.

Delivering as separate teams in a same sprint creates a lack of ownership for the feature.  The challenges are coordinating the teams working on the same feature and making all teams accountable for design and delivery.

Cross-functional teams and vertical slices

Part of the solution is to create multiple cross-functional teams, which have team members with the complete mix of skills necessary to deliver a project or at a minimum an increment of functionality in a sprint.  Using my earlier example from the web company, this means you would have multiple teams of between five and nine team members with a mix of integrators, server-side developers and designers.

Building cross functional teams allows the option of having the teams work on different projects or share a single Product Backlog but tackle different features.  For simplicity, figure 2 below shows multiple teams working on the same project but on distinct features.

Figure 2 - Vertical Teams working on features

The purpose of creating these cross-functional teams is to reinforce the ownership of an entire project or entire pieces of functionality by a single team.  Being together in the sprint planning and daily meetings simplifies building a common understanding of what to build and allows them to coordinate their efforts to deliver the functionality inside the sprint.

The other purpose is to force the teams to slice the functionality vertically, meaning end to end (i.e.: a working slice of functionality) instead of component by component (i.e.: user interface, server-side, design).

Before doing any coding, the team should discuss a feature and decide on the best approach to deliver something that will work end-to-end, manage risk and help them learn something useful for future sprints.

In a training class I gave recently, my students were building a paper prototype of a website over multiple sprints.  The challenge they faced in many sprints was building more into a feature than they needed from a user perspective.  In one instance, they committed to build group discussions functionality on their social media website.  Instead of keeping it simple in their sprint and allow users to create a group, join an existing group and post on a wall, they also designed functionality to manage all their groups and invite friends to a group.

Building only the most essential pieces first gives you less work to do up front and is the key to being able to deliver working functionality in a short development cycle.  It takes time to learn because it doing this goes against our traditional development habit but teams can learn to do this effectively with practice.

Figure 3 shows some example increments for an online ticket sales web site where users can buy tickets for live events.  The first increment would be for the team to allow users to buy a single ticket for a single hard coded event.

Buying a single ticket at a fixed price would allow the team to address the risk of integrating with a third-party (i.e. the credit card processing vendor) early in the project and proves the core of the system would work.

Figure 3 - Sample increments of functionality

The next increment builds on this foundation by allowing a customer to select a ticket category and the number of tickets to buy.  These additions would prove the website could also handle different ticket prices and calculating totals.  In our example, the team would also suggest the best available tickets for the category the customer selects.

Finally, in the third increment, the team would allow a customer to select the event for which they want to buy their tickets.  This means customers would see a list of available events from which they could select one and view the event details.  From the details page the customer would use the existing functionality from previous sprints to select the ticket category and the number of tickets and would buy their tickets.

Minimum feature sets

Earlier, we spoke about delivering potentially shippable increments of functionality every sprint to allow users to begin using them right away.  When working on an existing system, it may be possible to do this, the team just needs to think through the development sequence differently.  Developing smaller increments of functionality may also cause the team to refactor their code or rework in the same areas of code many times.  The code refactoring challenge will be even greater when teams are working on updating an existing system not developed with incremental delivery in mind.

Even though you gain flexibility developing and delivering a new system it may not make sense to put the pieces in production at the end of each sprint.  For example, if we come back to our online ticketing website, our users may have no particular use for a website that only allows you to buy a single ticket from a single event.  What you really need to do is understand the minimum feature set that would make your release a usable release for users.

Identifying the minimum feature set for a release allows the team to have a high-level view of what they will need to deliver in the end.  As you can see in figure x, the term “release” represents the results of multiple sprints assembled together.

Even when not delivering to production every sprint, you still want the team to develop completed end-to-end increments every sprint. At a minimum they allow you to show your stakeholders how the project is progressing and gather feedback regularly to make sure your team is developing the right solution.

Having completed increments also allows you to minimize waste if you ever decide to stop a project early.  For the sake of discussion, let’s assume you are working on a maintenance project and delivering completed pieces of functionality to a production environment every couple of sprints. Unlike a traditional project where you deliver everything at the end of a project, the completed and deployed pieces will remain available to users even if management decides to stop investing in the project.

Conclusion

Cross-functional software development teams have the expertise needed to deliver complete incremental pieces of functionality inside a sprint.  These teams also feel a greater sense of ownership over the functionality they are building.

Deliver smaller increments of functionality at a time allow teams to better manage risk and also allows them to show stakeholders the progress of the project by regularly showing pieces of working software.  Switching to a mindset of delivering small end-to-end slices of functionality is one of the biggest challenges new agile teams face.

The increments the teams deliver do not need to go to production every sprint but they need to be complete.  This allows the Product Owner as well as the team to gather feedback from external stakeholders.  Building smaller pieces at a time may also force the team to refactor code in a later sprint to add more functionality to a previous increment.  For new projects, understanding the minimal feature sets needed to allow a release to be useful for users can help the team determine target sprints for releases to production.

One of the keys to delivering working increments of functionality in a sprint is building cross-functional software development teams to work on them.  Encouraging these teams to think through the purpose of a feature before coding can help them discover the smallest end-to-end piece of functionality they can develop in a sprint.  Being able to do effectively is the difference between having an agile mindset in your projects versus just using an agile development process.

About Web and PHP Magazine

Web & PHP Magazine dives into the latest front- and back-end developments and practices in the world of PHP and web technologies, with feature articles by industry experts and innovators. Web & PHP is a community resource, so completely free to download!  Visit our website at http://www.webandphp.com.

This article originally appeared in the December 2012 edition of Web and PHP magazine and is republished with permission.

Many web design firms work on too many projects simultaneously.  When these firms start using agile software development practices, it forces them to look for different solutions to develop and meet the needs of their customers.  This article presents ideas to consider if you want your web development teams to focus on one project at a time.

Let me guess, you work in a small web design firm and are working on ten projects simultaneously.  Your management team heard about Agile, thought it would be cool so they decided to hop on the bandwagon but somehow, it is still taking forever to deliver a single project?  Are you feeling overwhelmed?  Is it a frustrating situation for you and your team?  There is a solution you know, it starts by imagining what could happen if you focused your people on one project at a time…

I worked with a few small companies in the last few years and before transitioning to using Agile practices, they used to spread their efforts across all their projects pretty much at once depending on which customer screamed the loudest.

Do you really need to focus on all these projects at once?  The answer I usually get when I ask this question is because there is a need to meet customer commitments, but I found that often the real challenge is in how to properly manage customer expectations.

Figure 1 below shows the problem with working simultaneously on multiple projects is the high cost of context switching between each project.  Each time team members switch projects, they must remember where they last left off and put themselves back in context.  What may seem like a ten to fifteen minutes to get ready for your day actually has a multiplier effect when you touch many projects in a day.

Figure 1 - Effect of task switching on efficiency

There is no magical answer for the number of projects a development team should simultaneously work on, because it depends on the size of the projects and the team.  In one context, you have your team of five or six people working on two websites at once. In a different context, the same team of five or six people may be working on a single large website.

The ability to share and spread work among team members on a single project is one of the factors that may help you decide.  For example, you may not benefit having the entire team working on a single project if team members would step on each other’s toes doing that.  For the sake of this article, let’s assume the entire team could work on the same project an entire sprint.  For you agile newbies, a sprint is a two to four week period of time during which your team works together to deliver a working piece of functionality.

Accepting that possibility, the next question to ponder on is how long should that team focus on that single project?  Is it a good idea to focus the team on one project for multiple consecutive sprints?  Should the team focus on a different project every sprint?  This is where properly managing customer expectations begins to factor into the equation.

The main complaint I hear around focusing on one customer at a time is the turnaround time when asking customers for feedback or data entry.  If this is your case, I suggest you consider how well you are communicating and collaborating with your customers.  They need you to let them know what you will need from them ahead of time to free up the key people that can support you.  If you continually make last minute requests, they will not be able to handle them quickly.

How can you foster tighter collaboration with your customer?  It starts right at the beginning of your project, while you are deciding how you will work together.  Begin by telling your customer you will develop their website using agile practices and this means you will want to involve them early and often during the development cycle.

Ask them to appoint someone on their side who will collaborate daily with your development team.  Depending on how open and collaborative you want to be, you may also want to invite this person to sit with your team in your office every day while you are building their website.  Let them know this person will need to make decisions on the project and you will refer to this person as the Product Owner.  Inviting a Product Owner to come work with your team every day is a powerful way to make sure your team focuses on a single customer, on a single project at a time.

The other important thing is to let your customer know when you will have a development team ready to work with them.  Give them a timeframe and explain the high level steps of your development process.  This will help them better understand when they will need to free up the Product Owner to collaborate with you.  Another benefit of having their Product Owner on-site is this person potentially has various contacts in their company that can contribute with some extra testing and data entry when necessary.

At this point, the next objection looks something like: “But I have ten projects on my plate, I cannot tell my customers I will not work on their site for a few months!”  Again, how are you managing expectations?  Do your treat your customers as your business partners?  If historically, there was a rocky relationship between you and an existing customer, you should focus on trying to fix those relationships.  You can start doing that by apologizing to your customer for collaboration issues of the past and then explaining how you would like to work together moving forward.  Your most critical challenge after this conversation will be living up to your collaboration promises.

The next thing you may want to consider is to start focusing on emptying your pipeline of current projects.  The question forces us to return to our original questions about having all the team members focusing on a single project or having the team work on multiple projects at once?  How the team shares the workload on a project remains the answer.

For the sake of discussion, let’s say a team has a designer, a couple of back-end programmers and a few integrators for the UI work.  What happens when you propose that the entire team swarm and work together on a project?  Are they protective of their pieces?  Do they flatly refuse because they feel they will step on each other’s toes?  My first question to them would be to ask them what happened the last time they tried.

This may cause an interesting reaction because they possibly never tried doing this and they are letting a big assumption get in the way of experimenting around it.  The follow-up is to ask them to try it and see what problems they run into and see what they learn from the experience.  Assuming you have two weeks sprints, how much time would this experiment cost you?  Worst case, they will try for two weeks and stop doing it but what if they find a way to make it work?  Consider how much faster you may deliver a project if you could double the staff working on it?  You should be able to find some benefits even if you do not double your productivity.

Let’s assume you can convince your team to try it and let’s pretend as well they find issues doing it.  What next?  In these circumstances, the Sprint retrospective is the perfect place to discuss these challenges and find solutions to improve their effectiveness.  The truth is the team will never know what they need to change until they commit to maximizing their collaboration and pushing themselves out of their comfort zone.

How else can you reduce your project pipeline if you focus a team on a single project at a time?  The most obvious solution is to create more multidisciplinary teams to assign projects to.  As you staff the teams, you need to find a combination of knowledge and experience for each of the teams; this will allow them to tackle the widest range of projects possible.

You must reduce the number of projects in your pipeline before adding more new projects for the teams or at a minimum, slow down the pace for new projects coming in to allow the teams to catch up.  Once you reduce your pipeline of existing projects, it will enable you to get the teams in a constant rhythm and will allow you to more closely collaborate with customers on new projects.

Conclusion

Focusing your development teams on a single project at one time may seem like a crazy idea, but it will allow your team to focus and become more predictable in the long term.  The key to allowing your teams to focus is by developing a closer working relationship with your customers.

Inviting your customers to provide a Product Owner to work onsite with your teams will force you to focus on their projects and show your willingness to be transparent with your customers.  This transparency will force you to improve your processes and may eventually provide you with a competitive advantage.

The key to being able to focus an entire team on a single project is to challenge them to do it and encourage them to focus on finding solutions to any collaboration issues they run into.  Allowing them to work separately does not foster collaboration and shared ownership of the project.

About Web and PHP Magazine

Web & PHP Magazine dives into the latest front- and back-end developments and practices in the world of PHP and web technologies, with feature articles by industry experts and innovators. Web & PHP is a community resource, so completely free to download!  Visit our website at http://www.webandphp.com.

I miss my website!  I went on a bit of a tear last fall writing about Tribal Agility.  I will complete the series, I have more posts to put up on the topic.  If it seems quite here, it is because I spent much of the month of January writing either for Web and PHP Magazine or the new website of my TL Approval Process at provokingleadership.com!  Our goal on that site, is to write articles to provoke leadership around us.  If you are curious, I invite you guys to come and read my posts there as well, you will find different style of Steffan that is a bit more edgy.  This site will continue to live on, there is more Tribal Agility coming in the next few weeks!

I mentioned in one of my blog articles that I was trading e-mails with Dave Logan, one of the authors of Tribal Leadership, about the Tribal Agility articles I wrote for my website last month.  This discussion turned into some articles getting republished on the CultureSync Website!  To see where you can access the articles on their site, I invite you to read on…

CultureSync republished the triad articles called “An Introduction to Triads” and “How to build triads on your agile team” as part of the Advanced Tools in the Toolbox section of their website.

In the Community Tools of the Toolbox section of their website, they also graciously added a direct link to the “Identifying the stage of your agile team” article on this website.

Thank you Dave and Becca!  I look forward to collaborating more with CultureSync in the coming weeks and months!

I spent three days at the CultureSync Leadership Unleashed last week and the time I spent here impacted me in some scary ways.  In one session, we spoke about the Batman effect and used that story to help us identify our great gift.  My great gift was something I did not expect and this had a strong effect on me this week.  To learn more about the Batman effect and the impact of learning my gift, I invite you to read on.

I will write another blog post about the Leadership Unleashed event but I wanted to keep this separate because for me, this was the best gift I got out of the entire event.  Let’s start by talking a bit about the Batman effect.  To learn more, I invite you to listen to this clip of Dave Logan explaining the Batman effect in one of his talks.  The relevant piece is between the 12:40 and 14:00 mark of the video.

During the live event this week, Dave Logan spoke about the Batman effect in similar manner to the clip above.  After his talk, we needed to work in triads to identify the great gift we bring to the world.  As I often did in the last few years, I brought it up in terms of the stuff I can do.  Specifically, I spoke about my ability to communicate difficult concepts in layman’s terms that most people could understand easily.

Someone at my table challenged me on that and told me that something did not sound quite right about it.  He could recognize my communications skills were possibly good, but that was not the gift I bring that can change the world and that somehow, it just sounded hollow.  Unable to think of anything else, I invited one of my approval stage triad mates Carrie to chime in and help me.

The first thing she asked me was for me to name what I thought was my greatest gift.  So I told her about the communication aspects, she looked at me and smiled and told me something close to: “That’s not it, your gift comes from a different place, look inside yourself and you will find the true answer“.

So she asked me if I trusted her and I answered yes.  She asked me to close my eyes, put my hand on my heart and ask to see what would come up and the answer I got was “empathy”.  This may seem like a good thing, but realizing this is my great gift occurs to me like giving Superman a bar of Kryptonite and telling him to use this gift to change the world.  Carrie was amazingly sympathetic when she saw the effect this realization had on me.  We had a fun moment lying outside on the ground looking up at a gray sky with light rain falling on us and talking through it.

Remember in the Batman story above, there is a point where Bruce Wayne, locked in a box, desperately waiting for Batman to come save him suddenly remembers that HE is Batman.  Once he realizes this, he breaks out of the box and beats up the bad guys.

That specific moment came to me at 4:00am the next morning.  Unable to sleep, I remembered my great gift is much larger than just empathy it is the ability to read people and feel their emotions.  My gift is also finding the words that give them courage or inspire them to try something they would not dare to try before.  Remembering this also resurrected how much this gift can hurt because you do not always feel positive energy, you may not want to feel it and these things may deeply hurt you.

I also realized that I consider this Kryptonite because of what I associate to leadership.  Leaders must be strong for the people surrounding them.  I realized this needs to change to “Leaders must be strong for others when they need it but strong leaders must be vulnerable to inspire people to greatness”.

At that moment in time, at 4:00am, I reflected on the past day and it occurred to me that I finally fully remembered the gift that turns me into some form of “Batman”.  I finally learned what I need to step into and accept to powerfully change the world around me.

Today, I decided to change how this emotional side occurs to me and instead of considering it weakness I found two new ways to help myself accept.  The first is what can happen with people taking anti-depressants or anti-anxiety medicine for a long time.  These will make you numb emotionally and when some people get off them, feeling what they were no longer used to feeling seems like something very raw and overwhelming.  They feel this way until they can manage their own feelings again.

I also found that I could look at it as a radio that startles me because it is always at maximum volume when I turn it on.  Eventually, I will learn to check the volume knob but until I do, I need to accept the sound may initially startle me and I need to turn the volume down a few notches.

On my last day at Leadership Unleashed, I shared much of this with people around me.  I had a very emotional day in service to myself and others and learned people found me to be different and much most present.

Thank you to Carrie and David.  Both of you truly bring out the best in me and push me in unexplored territory!

Have you ever felt like you are standing on the edge of cliff and if you dare take that next step something totally amazing will happen?  That is where I am in my life right now.  In the last few weeks, many fascinating things happened around me and there is this strong feeling I am merely a step away from doing something that will totally change my life.  So what does this feeling have to do with the title of this post?  I invite you to read on to find out!

Many amazing things have been happening all around me in the last few months.  Things ranging from my really great and supportive triad in the Tribal Leadership approval process stage to all the blogging around Tribal Agility.  I am in an interesting discovery process right now and I am rediscovering a part of myself that I ignored for a very long time.

The Tribal Agility blogs allowed me to connect with Dave Logan, one of the authors of the Tribal Leadership book.  More importantly though (sorry Dave!), they allowed me to put together and verbalize some of what I learned around how to combine the knowledge I acquired Tribal Leadership Intensive classes and how I work with Agile teams.

I came out of the Intensive class with a basic understanding of the concepts but I did not understand how to put them into practice.  It took me over a year after taking the class taking time to notice to see that I finally got it.

The dirty little secret of my blogs since September is the person who is writing them.  Before I share more on that, let me say I am one of those serial achievers in life.  I succeeded at many things because fortunately, I was always in jobs that allowed me to live my life with passion and just dig in.  My various job roles and personal experiences also stretched my abilities in all sorts of directions.

What took me a long time to realize though was the personal cost of reaching all those achievements.  While I had opportunities to have fun and do amazing things, the person that did those things defined himself by his ability to do them.  He had a continuous need to find bigger challenges just to prove to that he could beat them.

Imagine the size of the challenges you need to feed such a beast…  How long could you feed it?  Personally, I fed it for close to twenty years and I probably still throw the occasional steak down the stairs to feed it to be completely honest.  To come back to one of the personal costs, I learned to put aside the part of myself where emotions, fear, doubt and uncertainty live.  The achiever side was very effective at suffocating any of the occasional appearances of this “weaker” side.

In the last year two important things started happening.  I started noticing the more vulnerable side is much more present and I also started realizing the achiever side is reaching a plateau.  I understand now they need to come together if I want keep going higher.  You can only imagine how much chaos this is causing me and my belief system right now but seeing this other side wants to come out and play, I needed to find a way to let it breathe.  Since September, the more authentic and vulnerable Steffan is the person writing the blog posts.  I noticed this changed the tone of the site and creates nice freak out moments for the achiever, with posts such as this, which exposes the vulnerable side.  Creating that space is allowing them to co-exist more easily now.

How did this change happen?  I am not sure yet but I believe coaching and working to help develop people needed more empathy than the stronger side of me could muster.  I selectively started tapping the strengths of my emotional side when it was a necessity and eventually the genie escaped the proverbial bottle and now it refuses to go back.

Back to that feeling I was talking about earlier about taking that next step.  These days, I see this new person standing right in front of me which is a combination of the achiever and the emotional.  This person can break through the achiever plateau and achieve even bigger things by using the strengths of both sides.  Here is the thing though, I realized lately this person really scares me because he feels like a stranger right now and I do not know what it means to be that person.  What happens if this person is weak?  What if I lose the abilities of the achiever?  What if I do not like this person?  What if I cannot live up to the image of this person in my mind?

This person right in front of me is just standing there right now waiting for me to step into him and breathe life into him.  I am realizing lately that much of the journey in the last year was making my way to find this person and see him up close.  The positive is that I am much closer to taking that final step than I was a year ago.  That last step though feels like a complete leap of faith, similar to taking that step off that cliff and discovering an invisible rope to prevent me from falling and lead me to the other side.

There are times when I accidentally step into that person for a brief moment in time but when I realize where I am, I take a step back.  The effect this person seems to have on people overwhelms me and startles me which makes me the step back.  I had such a moment today speaking with a client.  We were speaking about what is going on in their organization and as I wear multiple hats working with them, the person told me the question was for the organizational coach in me.  In that moment, we spoke about many things including many topics around Tribal Leadership and I stepped in naturally into my Self.  As I was speaking, I could feel the passion and authenticity coming through my words and I could see how my words were inspiring this person to want to take action.  There are times though where I hear the call to step forward and I desperately want to get up but I feel paralyzed by fear.  The fear of stepping into my Self, exposing my true Self which I know gives people hope and then risking complete failure is too much for the achiever in me to handle.

So here I am a step or two away from stepping into my true self and becoming someone that will have tremendous impact, inspire passion, influence people and potentially make their world a better place.    All I need to do is find the courage within myself to take one big leap of faith that will allow me to transcend into the inspiring leader hidden inside me.

What stage does your agile team gravitate around?  Are you leading a Stage 2 team where the center of gravity is life sucks?  Or are you in a tribe of high performing Stage 3 achievers that do not play well together?  This week, as part of my continuing series of articles supporting my Tribal Agility talk, I will present some easy signs to help you identify the current stage of your Agile team.  To learn more about these signs, you will have to read on.

Before I start, I realize that eventually I need to write an article around these five tribal Stages I keep talking about in these articles.  Time is a very limited commodity right now, so instead, I will refer you to table 1 below which gives you an overview of the five tribal stages.  As an alternative, I invite you to visit the Toolbox section of the CultureSync website to learn more about the stages.

Table 1 - The Five Tribal Stages

When I present the stages to people, they typically believe they absolutely need to reach Stage 5 where “Life is Great!” The reality is that reaching a stable Stage 4 environment where teams collaborate well together or even just moving out of a Stage 2 where negativity and sarcasm rule can be a big step forward for a team.

Every stage serves a purpose and has both a healthy and unhealthy side so understand that teams cannot just skip over a stage, instead, they need to find ways to grow through them together.  Accepting the current stage of your team and deciding together where to go next is much healthier than just desperately trying to reach the “better stages”.

The tribal stages and agile teams

Often, the teams I coach are new to working using Scrum and after a few months working together, I find it useful to step back and look at how the team evolved since their first sprint working together. Agile teams do not necessarily start at Stage 1 and move their way up to Stage 4, they typically start at the stage where most team members are gravitating around.  A team with many individualistic overachievers will increase the odds of having Stage 3 team right from the start but what does this mean?  When you look at the various meetings in Scrum, how do teams or even individuals at the various stages typically act?

Please note I may exaggerate my examples at times by creating stereotypes or caricatures to help you better understand the differences between the stages.  Also note teams produce their own gravitational pull which pulls team members at different stages than the dominant stage up or down into that center of gravity.  One variation to note is that stage 3 is symbiotic with Stage Two, so while there is a center of gravity around Stage Three it will invariably include Stage Two members. I will begin by referring you to table 2 below to show you the various meetings in the Scrum framework and what teams use them for.

Table 2 : The Scrum Meetings

Signs of Stage 2 individuals or teams

Stage Two Agile teams are all about the lack of commitment and accountability.  Typically, these teams look disinterested, bored and do not believe in what they are doing.  They love using excuses for their failures instead of taking responsibility for finding solutions to overcome their challenges.  From the outside, they sometimes look like a group of people that do not want to work together.

As with many other team meetings, the Sprint Planning meeting will probably start late.  During this meeting, they look disengaged, bored and they keep collaboration between team members to a minimum.

On teams using post-it notes to track their tasks manually, the hard core team Stage Two team members will refuse to write their own tasks and will typically let others do it for them.  They will also precede any time estimate for their tasks by a disclaimer or excuse surrounding the uncertainty surrounding the task.

Speaking of tasks, when breaking down a backlog item into smaller tasks for the sprint, a Stage Two team lingers and argues on every detail.  They seemingly also work really hard to ensure they cannot come to a consensus on the work they need to carry out.

At the end of the sprint planning meeting, the team meets any confirmation attempt of the planned workload for the sprint, with some well placed sarcastic comments and they will make commitments they do not believe in from the start.  They commit because they strongly believe they have no choice in the matter.

In the daily scrum meetings, members of Stage Two teams still look disengaged and this meeting may not even happen on days the Scrum Master is not around.  This meeting is all about self-organization to meet the sprint goal but Stage Two team members do not care because they are going through the motions in the sprint.

Certain dysfunctions, such as not listening to one another or not making clear commitments for the day are rampant in the daily scrum meetings of Stage Two teams.  Team members will also ensure they raise any excuses they can for not completing their planned work.

In the sprint review meeting, Stage Two team members will seemingly not care about whether they complete their work or not at the end of the sprint.  Instead, they focus on why they cannot finish their work in the next sprint.  They question why it matters instead of questioning what they could do differently.

In the sprint retrospective meeting, Stage Two team members do not discuss real issues because doing so may force them to be accountable for finding a solution.  Even when these teams have some tensions within them and people will snipe at each other, they never openly discuss their personal issues to address them.

Stage Two team members never seem to be able to find solutions for their problems as well in a retrospective.  Fortunately they can identify all the problems they are facing but unfortunately there is no possible solution to address them.  The other challenge of these team members is that even when they identify solutions, their commitment to putting these solutions in place is usually pretty weak.

In a sprint retrospective, Stage Two team members do not focus on nor do they understand the meaning of the word “Team”.  Any discussion around the subject will cause discomfort and silence.  Silence is the perfect tool of a team or individual gravitating in Stage Two as it allows team members to avoid hard discussions and accountability.

The awareness that lives of some people around me does not suck is the main difference between Stage One and Stage Two.  This awareness indirectly offers hope and the possibility that one day, my life can be better.

Signs of Stage Three individuals or teams

Stage Three Agile teams are all about individual performance and the lack of collaboration and teamwork.  Because these teams have high performers that do not work well together and continually argue, it produces a culture of blame, lack of accountability and lack of transparency.  Team members also hoard knowledge because in their minds, knowledge is power. Because Stage Three is about individualism, I will focus on Stage Three team members instead of teams.

In sprint planning meetings, Stage Three team members will take a lot of space in the meeting and will squash the opinions of any team member they perceive as weaker than themselves.  They will also make sure everyone knows their areas of expertise and they will try to bully the team into doing things their way

They will obfuscate tasks and estimates as much as possible when identifying their work because they believe having the wrong estimates or wrong tasks on the board could expose they are not as great as they think.  They often equate transparency with micro-management so they complain and say “Just trust me, I will get it done in time.”

In daily scrum meetings, Stage Three team members will not ask for help.  They will claim their work is on track even though in reality, they are running late.  They will get upset and defensive about their work when team members challenge them during the meeting and may even attack the competence of the person challenging them in self-defense.

In sprint review meetings, Stage Three team members will find ways to present their work as complete, even when there is work they did not complete.  They will brush away any challenge when people suggest their work is not complete even though they will plan this extra work in the next sprint. They will blame other team members for not completing their part of the work for a backlog item if they completed their part even if their own late delivery caused the entire team to fail to deliver.

In sprint retrospectives, Stage Three team members will not accept any responsibility for their actions that cause breakdowns on the team and will always have explanations to brush responsibility away.  These team members do not understand the team concept and will always place their personal interests above the team. The word “team” occurs to them as “me and my minions.”

The insidious side of a Stage Three team member is they will feed on the complaints of Stage Two team members to build their case for their own complaints.  They will also feed the resentments of Stage Two team members to build their own support structure.  Sometimes, when they know other team members have the same complaints they do, they may even tell you others feel the same way they do in a whispered voice to rattle you with “secret” information only they have.

Because it is a stage of performance and excellence where high achievers continually seek to prove their greatness, Stage Three has a healthy side as well.  The real danger of this stage is when these achievers want to win at all cost and they ignore the collateral damage they create around them.

Signs of Stage Four individuals or teams

Stage Four Agile teams are all about putting the team first, collective results, collaboration and teamwork.  These teams focus on building their credibility by leveraging the strengths of each individual on the team to achieve high quality results.  Stage Four teams enjoy working together and they trust their teammates to always have their backs.

In a sprint planning meeting, Stage Four teams collaborate enthusiastically.  They will draw on whiteboards to build a common understanding and may form smaller teams to help speed up the process.  Stage Four teams believe in productive conflict and are comfortable challenging each other on their ideas and on their estimates.  Their focus is on delivering value to their customer, the Product Owner, by listening to his business needs and building the right solution.

In the daily scrum meeting, Stage Four team members listen to one another and offer help when other team members need it.  They use this meeting to coordinate their dependencies and make sure they can meet their sprint goal.  If they realize their sprint is in jeopardy, they try to find alternate solutions as soon as possible to propose to their Product Owner or they let him know what they feel they will be able to deliver.

Stage Four team members are also comfortable challenging one another during the daily scrum meetings on the commitments they make to one another.  When a team member does not deliver on his or her promises, other team members step up to ask them why.

In sprint review meetings, Stage Four teams take collective ownership of the results the team produced in the sprint.  Because the team collaborated with the Product Owner throughout the sprint, they know they are delivering the right solution to meet his business needs.

In the sprint retrospective meeting, Stage Four teams aim for continuous improvement.  They accept everyone made the best decisions they could with the information they had available at the time.  Team members understand there is no use in playing the blame game so instead, they accept mistakes and focus on finding solutions.

Stage four looks like a healthy stage where team members collaborate in a world full of sunshine and rainbows but it has some unhealthy sides to it as well.  For example, some team members may not bring their true greatness because they fear how other team members, unable to produce at their level, will react.  This can lead to an entire team unconsciously lowering the bar so everyone can pass instead of supporting one another to keep reaching greater heights.

On smaller teams, another side effect this can create the illusion of a Stage Four team when the team has no real center of gravity because there are not enough team members to ground the team in a particular stage.  Artificial harmony is a strong characteristic of these teams.

Conclusion

Agile teams, like any tribe, will gravitate through the five tribal stages at various times and the stage with the critical mass of team members will become the center of gravity of your team.  This notion of critical mass implies team members will be at different stages at various times.

Understanding how to read the signals at the various stages presented in this article will help you better coach your agile team.  In the next article, I will discuss ways to help you raise the current tribal stage of your team.

In my last blog post, I wrote an introduction to triads.  The popular question I got by e-mail from a few readers was: “Nice idea, but how do I apply this in real life?”  As part of my continuing series of articles to support my Tribal Agility talk, I will write about building triads in agile teams this week.  Are you working in an Agile environment with a stage two tribe?  Would you like to use triads to break through collaboration barriers?  To learn more, I invite you to read on.

Agile teams and Tribal Leadership are very compatible with each other.  Lately, I spoke with people in various companies that adopted agile practices and asked them the benefits they were looking for out of agile.  Aside from the usual points of increasing return on investment, speeding up time to market and increasing collaboration, another common sought after benefit was increasing employee engagement on their projects.

You want your Agile teams to be self-organizing and take full ownership of their projects but this can be difficult to achieve.  Speaking with these people in pre-engagement conversations, they mention the need for people taking more ownership of their projects and shortly after, they express how far they feel they are from that goal.  The question I usually ask them at that point is: “Have you made this clear to them this is what you want?”  After hearing their answer, my follow-up question usually is: “… and how do you react when they make mistakes?”

Triads can help you move more rapidly towards achieving the goal of building a self-organizing team and it all begins with how you act as a leader.  As an agile leader, you need to be able to delegate some of your authority to your teams and empower them to make certain decisions.  You can use delegation poker and delegation boards (from Management 3.0 by Jurgen Apello) to help clarify what you are delegating and who you are delegating the authority to.

Agile teams typically have between five and nine team members which present an opportunity to form multiple triads on a team.  To help you better understand how to build triads, let me tell you a story about Joe, a Scrum Master working with an agile team.

Joe is a Scrum Master and he wants his team to take more ownership of the project.  On his team, he has people from different departments (development, quality assurance and information development) that need to collaborate to deliver features to their customers.   Most team members being relatively new to the company, they are not yet comfortable with the existing systems.

After two sprints, he begins to notice the developers rarely speak to the people from the other departments.  He also notices everyone is sitting in their separate cubicles, in different areas of the same floor which he feels is not helping their collaboration issues.

In the following retrospective, he asks the team what are their most painful challenges.  After a long discussion, the team comes up with the following issues:

• Lack of expertise to tackle incoming support issues
• Lack of communication between people working on the project
• Lack of a common understanding of the project vision

Having just come out of the Tribal Leadership Intensive class, Joe begins to wonder if using triads could help overcome some of these challenges on his team.  He decides to suggest some new ideas to his team.

Figure 1 - Support Triads Benefits

Carrie, the rock star developer, is the person with the most knowledge of the internal systems.  When big problems occur, she is typically the one that will fix the issues no one else wants to get close to.  Joe suggested pairing her with another developer and one of the testers the next time a major support issue comes in.  The two developers could resolve the coding issue together and the tester would confirm the fix.  Figure 1 shows the benefits this triad would provide.

The team decided to try this solution for a few sprints.  Joe asked the team what they wanted to do about the two other issues.  A team member sought more details about the lack of communication in the team.  Jennifer, of the testers, mentioned she did not know what to build her test cases around because the design of the feature kept evolving throughout the sprint.  Seemingly, the developers regularly deliver something different from what she understood in the sprint planning meeting.  This causes her test cases to be wrong which force her to rewrite them and start her testing late which is why she is rarely able to finish her testing in the same sprint.

A team member suggested that Jennifer go visit the developers more often during the sprint but she answered this was sometimes difficult because some of them do not like when she interrupts their work.  She also said she did not always know who owned the feature she was currently testing.  Joe saw the opening he was looking for and asked who felt any ownership over what they were doing on the project.

Some people answered yes while some glanced back at Joe with blank stares.  Joe asked the team what it would take to allow them to feel more ownership of their features.  The team talked about all the features they were working on and how spread thin this made them feel.

Figure 2 - Development Triad Benefits

The team decided they could be more efficient if they created sub teams that would have ownership of specific features in the sprint.  The team had four developers, two testers, one technical writer, the Product Owner and the Scrum Master.

Joe suggested they try using the three people format they used for the support challenge.  He asked the team how to best spread the talent to allow each team to do the widest variety of work.  The team decided the best solution to start would be teams of two developers and one tester.  Figure 2 shows the benefits these development triads would provide to the team.

Figure 3 - Cross-team triad benefits

They were unsure on which team to put the technical writer.  Joe suggested that one member of each team meet with Len, the technical writer, a couple of times a week for one hour.  During these meetings, they should share thoughts and provide updates on the design changes made during the sprint.  Figure 3 shows the benefits this cross-team triad would provide the to the team.

To increase the communication, Joe also suggested all team members move closer to one another.  He took actions with the management team to create a new more open temporary work environment where everyone could sit with their triads.

At the end of the retrospective, Joe was happy because he started the meeting eager to find ways to set some up on his team and at the end of the meeting, he had four new triads on his team.

The next sprint planning meeting kicked off with excited team members looking forward to working with their new sub teams.  Joe reminded they put triads in place to create a three-person support system where everyone had each others back.  Each triad shared accountability for delivering the right solution and they were also responsible for supporting one another to make that happen.

During the sprint planning meeting, the first part of the meeting with the Product Owner explaining the sprint objectives happened in the same way it always did with all teams members taking part in the discussions.  When the team members were ready to break down the tasks, they agreed on the pieces they wanted to work on, split up in their triads and began identifying the tasks they needed to complete to deliver their feature.

Forming triads to work on the deliverables gave the team a stronger sense of ownership on their work.  They kept the same triads for multiple sprints as they learned how to work together in this way.  Later in the project, the team decided to experiment further by reshuffling the team members and building new triads.

All the communication and collaboration generated by the triadic structure also allowed the team members to more regularly talk about and take ownership the product vision with their Product Owner.  Shared common objectives and goals were driving the team and they began to achieve much more than before.

Conclusion

The above story does not show the growing pains triads go through but the goal was to provide some initial ideas on how you can create some on your teams.  Working with a Stage Two tribe or with Stage Two team members can seriously hinder the progress of creating triads on teams.   Once team members get over the learning curve of supporting one another and working as a team, they will start progressing faster more rapidly.

In an organization, triads are an excellent way to get people from different teams to collaborate on initiatives that interest all members.  For example, if an organization wanted to bring in some best practices like automated testing or continuous integration creating triads around these initiatives allows more people to take ownership and work with like-minded people to achieve a common goal.

The key to making triads work in any organization is the existing organizational culture.  Triads will thrive in organizational cultures where collaboration and cultivation rule.  Organizational cultures driven by command and competence will foster a Stage Three environment which will require different kinds of projects to allow triads to thrive.

Tribal Agility is my 2012 fall conference presentation. As I rarely give out my presentation decks, I wanted to try something different and create a page containing articles with the content of the talk on the web site. Please note you will not find slides on this page, only links to blog posts for some of the topics of the talk.

Read the Full Story

I wrote about joining a triad for the final stage of the Tribal Leadership approval program.  Putting three people together to carry out a project may sound nice but what does it mean exactly?  What does a triad do?  As I am preparing a talk for next month titled “Tribal Agility”, I decided to write an introductory piece to help feed the content of my presentation.  If you want to learn more about triads, I invite you to read on.

Many relationships are dyadic in nature meaning it is a relationship between two people.  The biggest challenge with these two people relationships is there is nothing to help stabilize them when a breakdown occurs.  Relationships of Stage three people are dyadic in nature because it allows the stage three person to control the flow of information between two people.

Take a moment to think about the discussions you have with people at work.  Do you have one-on-one discussions with several people about the same issue?  Are you relaying information from one discussion to the next?  Are you the central hub of a discussion between multiple people?  All these are easy signs you are building dyadic relationships.

A triad is always three individuals, not a group, trio or collection of individuals.  Triads are intentional, not coincidental because each member is actively responsible for the quality of the relationship between the other two members.  This intentionality forces the focus of triad members outward (toward others) rather than inward (towards themselves).

The theory behind a triad is that relationships need a third element to help them remain stable and the theory says the stabilizing element does not always need to be a person.  As an example, when writing the book “A practical guide to distributed Scrum”, one of my co-authors, Elizabeth Woodward, and I used to regularly debate the content.  In those instances, we would pause and ask ourselves aloud: “Putting our personal feelings aside, what is the best thing for the book?”  When I think back, I realize the book was our stabilizing element in our triad.

Practically speaking, there are three different types of triads:

• Relational triads
• Structural triads
• Power triads

Relational triads

In a relational triad, shared values bind the members of the triad as they are not necessarily working on a project together.  The difference between a relational triad and three people working together is how the relationship evolves.  In a stable, mature triad every member is responsible for preserving healthy relationships between all members of the triad.  Essentially, put Larry, Moe and Curly in a triad, and this means:

• Larry is responsible for the healthy relationship between Moe and Curly
• Moe is responsible for the healthy relationship between Larry and Curly
• Curly is responsible for the healthy relationship between Larry and Moe.

Figure 1 below illustrates the steps to build a relational triad.  It starts with one person introducing two other people based on common values or interests or a common need.  For example, keeping with our Three Stooges theme, Moe may introduce Larry and Curly.

In the early stages of this triad, Moe is responsible for building and feeding the relationship between Larry and Curly.  He is also responsible for making sure they stay connected.  Moe can do this through occasional phone calls to Larry and Curly to make sure they are getting the benefits that Moe connected them for.

As the Stooge triad stabilizes, they all become responsible for the relationship.  This means that if Moe and Curly have a conflict, Larry is responsible for helping them patch things up.  If Curly and Larry have a conflict, then Moe becomes responsible for helping them patch things up.

Figure 1 - Building a relational triad

How should you start creating relational triads?  Find ways to connect people that will provide a benefit for everyone.  For a real-life example, imagine creating a triad with a customer between an organizational coach, a team coach and the project sponsor to support an organizational transformation.  This can be a useful way to discuss strategy and issues faced during the transformation project. You do not need to call it a triad but these regular meetings will keep everyone synchronized.  The conversations in the meetings should promote basic common values such as communication, transparency and respect.  Naming these values as the purpose of your meetings allows you to set expectations but the key is making sure you always meet together instead of having one-on-one meetings.

As a coach of software development teams, I find it difficult to build relational triads with the teams I work with.  Randomly sitting down with a team to discuss values just feels awkward for people, even if they worked together for many years.  In my coaching role, I found the challenge is that I cannot create a bubble around the team to protect those values.   The values conversation needs to start at the management or organizational level, and the values of the team need to align (or at least resonate) with the organizational values.

Structural triads

In a structural triad, a shared project or shared pain points bind the members of the triad.  People create these triads out of necessity to serve a specific purpose.  Structural triads need a common objective which will bind help the members together.

Here are some examples of possible structural triads on a software development project:

• Three people (two developers and a tester) working on delivering a single feature.
• Three people from different teams (development, testers, writers) that need to coordinate efforts on a project
• Three people in different locations that need to synchronize on a project

All these triads should meet at a regular interval (daily or weekly) to discuss their common interest in the project.  These functional triads serve the purpose of breaking communication silos, helping one another and fostering collaboration.  These triads can also strategically elevate group culture by creating a project that people cannot accomplish without true collaboration.

Power triads

In a power triad, shared values and helping each other on projects of mutual concern bind the members of the triad.  They combine the qualities of Relational and Structural triads.  When introducing people to form a power triad, you need a shared or resonant value as well as a common need.  Without the values, you are just a good connector and without a shared need, you are just a good matchmaker.

As with any other group of people, I believe power triads typically go through Tuckman’s Stages of Group Development.  In the Forming stage, triad mates will remain cordial with one another, not necessarily sharing their feelings or disagreements.  A triad in this mode may either feel like a very clinical experience or like going through the motions without an end goal.  Triads where members are unwilling to share their values or vulnerabilities remain stuck in the forming stage.

In the Storming stage, reality starts setting in, real personalities start coming out and the triad members begin to share their values to discover their common values and objectives.   Triad members may also clash their objective of their common project and how they work together.  Triads that cannot agree on a common project (or noble cause) and shared values will remain in the storming phase.

In the Norming stage, the triad members know their shared values and their noble cause.  They also identified a project to help them achieve their noble cause.  Triad members compromised on their ideas and adopted ideas from others to achieve something greater than what they could build alone.  The triad has a microstrategy in place to begin achieving their project and members of the triad begin pitching their project to get other people involved.

In the Performing stage, the triad stabilizes at stage four and its members are working together and moving toward achieving their common noble cause or project.

Conclusion

Triads facilitate collaboration and help stabilize relationships.  They are also the building block of a stage four environment so people can also actively participate in multiple triads at once..  Building a stable triad calls for all triad members to invest in the common good and give up part of themselves to achieve something greater than they could build alone.

When you cannot build a relational triad, consider whether a structural triad would be helpful to address the problem you are facing.  Structural triads can help deliver short term results and may eventually become a relational or power triad.  Remember that you can also build informal relational triads by stating values as the intention of a meeting and by regularly meeting as a triad instead of using one-on-one meetings.

Before I close, I would like to thank my triad mate David Brown for reviewing this post and giving me lots of great suggestions to improve it!