Agile Transformation

Daily Scrum Personas

Daily Scrum Team

The Scrum Guide defines the Daily Scrum as a “15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours”.

Each person answers 3 questions:

  • What did I do yesterday that helped the Development Team meet the Sprint Goal?
  • What will I do today to help the development Team meet the Sprint Goal?
  • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

The Development Team leverages these 3 questions to inspect, self-organize and empirically adapt to deliver the Sprint Goal.

The above information is straight out of the Scrum Guide, but as we practice our Daily Scrum we just might meet up with some of these people, listed below, that will provide us some coaching opportunities.

I hope these examples are helpful for the person just starting to implement Scrum at their organization and a review for other experienced Scrum practitioners.  Anyone who has any additional examples, please feel free to add them as a comment and we can build on the list!


Larry “Looking for a Leader

Larry is 45 years-old and has been in IT for nearly 25 years.  All of those years have been working in a strong command and control environment. He’s a very structured individual and a compartmental eater.

Larry looks directly at the Scrum Master while answering the 3 questions.  This is a tell-tale sign that Larry is looking to provide a status report to a person in charge.  He has not yet embraced the philosophy of a self-organizing and empowered empirical team.  He should be speaking to the team and not any one person. Explain and reinforce the empowered empirical team through coaching, games and exercises.


Penelope “Problem Solver

Penelope went to well-respected university and was a double-major in Computer Science and Philosophy.  She doesn’t have much patience for useless formality or rules that get in her way.  She loves to dive into the detail and solve problems.  Her mantra is “Patience is a waste of time!”

Penelope conducts an immediate deep-dive into details surrounding information voiced during the Daily Scrum.  When an issue comes up during Daily Scrum, she asks questions and begins to solve the problem on the spot.  We need to coach Penelope and the team to list topics for further discussion in a parking lot or discussion list.  When the Daily Scrum is done then you can identify who wants to participate in the discussions.  There is no reason to involve teammates who are not interested in that topic.  The conversations can be conducted right after the Daily Scrum or later as the team sees fit.


Nicholas “New Guy”

Nicholas is 22 years old. He just graduated college and joined the company about 3 months ago.  He’s a little overwhelmed with all the things he needs to learn at the new job.  He’s hardworking, but insecure about the amount of work he can get done in a day compared with his experienced teammates.

Nicholas talks about anything he can think about that he did in the day, so that his team will not think he is unproductive.  He mentions the meetings with his manager and other non-sprint related activities.  Nicholas and the team need to be reminded that they need not speak about non-sprint related activities during the Daily Scrum.  They should only be speaking about information that pertains or impacts the sprint.


Sammy “Scrum Master”

Sammy was a project manager for 5 years until his company adopted Scrum and he transitioned to Scrum Master.  Sammy likes nice orderly meetings and ensuring that the team is on track for delivery.

Sammy sets rules for the team, such as punctuality, no interrupting, etc.  He sets the order in which people should speak to increase efficiency.  Although rules are not necessarily a bad thing, the team should create rules of engagement and determine the speaking order on their own.  We need to take every opportunity in having the team realize and practice that they are a self-organizing team.  Conduct activities and games to fortify this concept.  Try having the person currently speaking choose the next person to speak.


Priscilla “Product Owner”

Priscilla has worked for this company for 20 years.  She is very intelligent and understands the sales and advertising business very well.  She also loves technical work and is adept at pulling data and analyzing it.  She always wants the latest technology solution and, even though she works in sales herself, is an easy sell.

Priscilla listens to the Daily Scrum, but cannot help advising the team on how to order their work effort to be more efficient.  She questions remaining time on tasks and pushes the team regularly at the Daily Scrum. We need to counsel Priscilla that the Daily Scrum is for the Development Team to assess progress and figure out as a self-organizing team how to accomplish the Sprint Goal and deliver the agreed upon sprint backlog items by the end of the Sprint.  As the Product Owner, Priscilla should not be interjecting during the Daily Scrum.

How Should We Structure Our Agile Teams?

Agile Team

There are two types of teams, Functional Teams and Cross-Functional Teams.  A Functional Team, sometimes referred to as a Component or Specialty Team, is comprised of people with the same skill set.  Cross-Functional teams on the other hand are centered around delivering the same business value and consist of people with different primary skill sets.

The Functional Team benefits from frequently sharing and bettering their specific skill set knowledge across the team.  It is easier establishing and enforcing standards. Communication and collaboration within their specific skill set is very efficient, since they are all on the same team.

A Cross-Functional Team on the other hand benefits from having people with different primary skill sets so it can deliver the requested business value without or with minimal dependencies on other teams.

When looking at the two different team types, there are a couple of important questions we must ask ourselves to decide team structure.

Question 1:  Do we currently have enough people with that skill set so we can place a person on each Cross-Functional Team that has a need for that primary skill set?

We don’t want someone being a member of four different teams.  In fact, many Agilists believe that a person should only be a member of one team.  I believe there may be exceptions, but there should be a good reason for it and once you split a person across more than two teams it should certainly raise a red flag.

Question 2:  What will be the most important and most frequently needed communication and collaboration?  Is it with others with the same skill set or is it with people delivering on a common business initiative?

Communications with and dependencies outside of the team are responsible for most of the delay in software development.  If we can keep the need for cross-communications to a minimum, then we can minimize this delay.

I learned a valuable lesson a few years ago when I took an existing group of integration specialists and divided them up across cross-functional product teams.  On the surface this appeared to make perfect sense.  I thought the cross-functional teams would benefit greatly by requiring less hand-offs, better design decisions, simplified planning and improved speed of delivery.  What I didn’t realize was the integrations people needed to communicate more with each other.  The integrations code was legacy code.  It wasn’t very loosely coupled at all and every time you changed something you had to coordinate with the rest of the team.  Obviously, this technical debt needed to be addressed, but until that time it made more sense for the integrations people to be on one team.

The main point is to determine where the communication needs are and base your team structure on those findings.  After I learned this important lesson through failure, I also found a book, “Management 3.0” by Jurgen Appelo, which addressed the topic in “Chapter 13: How to Grow Structure”.  I highly recommend this book for this subject and other great information and insight.

Happy Team Growing!

Hey John, Don’t Abandon Agile!


I was speaking to my buddy, let’s call him John (quite possibly because his name is John). John is a good friend who also happens to be in software development.  We were having a nice chat about our families and such when our conversation transitioned to our work. That was when John dropped the bomb on me and said, “Hey Phil, I know you’re a big proponent of Agile and my company does Agile, but you know sometimes you just have to abandon Agile and get things done”.

I don’t think my buddy John is the only one out there thinking this way.  What Agile adopters need to understand is that Agile will uncover and shine a spotlight on issues.  If organizations don’t have a healthy practice of inspecting the issues, identifying root cause, creating action items and conducting remediation – then they won’t move forward.  Why did we miss expectations? And if you can’t answer that question then ask “why” four more times.  It is so important for remediation on prioritized issues.  If you don’t, then you might take the position to abandon Agile, but in reality you have not followed the rules of the game because you have not addressed the root issues Agile has uncovered.  If your organization has been practicing Agile for a while and you feel, as my buddy John does, then I would challenge you with the questions below.

Can you utilize retrospectives to identify the root cause, prioritize action items and at the very least chip away at fixing them?  Sure, you may not be able to address everything or even half of what you find, but can you commit to start?  What issues do you face?  Does your organization experience some of these issues below?

We can’t do a two-week sprint – it takes us a week to test this stuff!

The end goal is to create a test-driven development environment.  In the interim you can do your best to create automated tests.  It may not be easy, but start to carve out some time and at least create automated testing around some of your more visited code.  Try to adopt a policy to have automated unit testing done for new code.

OMG!  Look at this code!  This needs a complete overhaul!

Don’t grow technical debt without a conscious decision to do so.  Even if you don’t practice pair programming, setting up a practice where there are peer code reviews or more than one set of eyes on the code is good practice.  If you don’t do this, you are probably working in an environment where over 30% of your time is spent complaining about and/or addressing technical debt.

We conduct retrospectives and identify needed improvements, but we don’t have the time to fix them!

If you have a hard time acting on issues found in retrospectives, make sure you create product backlog items for the action items and prioritize at least some to be addressed.  Make sure you’ve identified the root cause and address at least one or two per sprint.

Man, they just keep loading us up with things to do – we can’t keep up with this!

This is tough if you don’t have executive support.  You’ve got to have prioritization in place for initiatives. Strive to get an agreement in place for a work in progress (WIP) limit at the initiative level. Create an information radiator Kanban board showing all the projects and their state so it becomes apparent to everyone that there is a lot going on here.  Cull and keep your product backlog to a manageable number and notify stakeholders when a product backlog item is being deleted.  There will always be a higher number of requests than can be done.  If the stakeholder does not want it deleted, then they need to make the case for its priority.

They just told us about this the other day!  How can we get this done!

Identify the root cause of why you received this request so late.  If this happens often then record these events in a spreadsheet and have a discussion with needed individuals to uncover root cause.  Did another department sit on this request?  Is it a late request from a 3rd party, regulatory body or vendor?  Do your best to meet with the appropriate people, address and fix the situation.

They keep on interrupting our current project with another emergency project!

When you start working on a project do you define the smallest amount of features that you can deliver?  This is considered to be the minimal viable product (MVP).  Small batches are more efficient and at least if you get interrupted you have a better chance that you will have delivered something.  An emergency can happen, but if it becomes the norm then you’ve got more digging to do for root cause.  If you’re constantly stopping one initiative to start another, then you also may not be working on the right things.  A lot of organizations don’t have the proper scrutiny around economic feasibility (possibly my next blog) and without that objective measurement the newest squeaky wheel can sell anything as an emergency. Software started and abandoned cannot be seen the same as unfinished product laying around the manufacturing assembly line, so this happens more than we like to admit.

We’re dead in the water waiting on this other team!

Strive to create cross-functional teams, so you are not so dependent.  In the beginning this can be tough and cannot be done for everything at once, but if you don’t try then you will pay the price.  The biggest waste in software development is found waiting on dependencies and cross-team communication.  Think of creating a Kanban board displaying cross-dependencies.  This can assist in identifying queuing issues.

This issue happens over and over and is just killing us!

Continuous improvement is needed.  If you identify issues, but don’t act on remediation then you are not going to grow.  Capture the action items in product backlog items and prioritize at least one every sprint if you must.

This code migration is taking forever!  The code worked in test so why isn’t it working in production!

Do your best to move towards automated builds and continuous integration and delivery.  Couldn’t leave this one out, but even like some of the others – this could be its own blog subject.

Is this Agile?  What the heck are we doing!

Get an experienced Agile Coach to guide you in your transformation.  It will be worth it.  When in doubt refer to the 12 Principles of Agile.

This guy sits right across from me and he’s emailing me on this!

Do whatever you can to create trust throughout your team and organization.  That’s one of the top reasons people continue to use email.  Try to speak to people if you can. Get to know the people you work with.

I can’t get all these tasks they gave me done!

Eliminate as many dependencies as you can.  Try not to work on more than one thing at a time.  Context switching will cost you 20% of your time per item.  The more cross-functional your team becomes the less chance that tasks will have to be done by one person.

As Agile implementations fail at some organizations because we didn’t address the uncovered issues, Agile will probably take the hit.  Let’s try and prevent that from happening, by just remembering to nurture, care, feed and grow our Agile transformations through continuous improvement. Hopefully, some of these scenarios have hit home and illustrated that Agile may not be failing us – we just may be playing the game wrong. Concentrate on continuous improvement for the issues that Agile is uncovering.

Oh, and John and I will still be the best of friends after this blog because, you know, healthy conflict is a good thing.  Love you brother!

Let the Agile Games Begin!

Dog Poker

I’ve wanted to introduce Agile Games to my teams for some time now and finally pulled the trigger with much success.  It was just before the holidays and like high school students attending their last day of school before the Christmas break, you can imagine that the team’s minds were not as focused as usual.  Yes, the perfect time for an Agile game!

I started off with a quick simple game addressing the effects of multi-tasking, interruptions and thrashing.  This was a game I believe I read about somewhere, but kind of rolled my own with the team.  Anyway – the game went as follows:

I had 4 teams of 3 people.  Each team had a space at the board.  Three columns labeled on the board for each team (“1-10”, “A-J”, “I-X” [the roman numerals]).  The first round I told person 1 from each team to write on the board the numbers 1-10 under the column 1-10 and then do the same for A-J and then the same for I-X.  They raced against each other and I recorded the person with the fastest time.  I then let person 2 of each team do the same and then person 3 do the same while recording fastest time.  We then went through all 3 people again only this time they had to write it in a different order.  They had to write one in the “1-10” column and then go to the next column and write A and then next column and write I and then return to first column and write 2 and so on.  I timed them all again.  At the end of the game, I asked them which took longer for them and obviously it was the second way of writing the symbols.  Why was this?  Because switching focus costs you time.

The game made it so obvious.  If you feel your team is having issues with context switching you could quickly play this game at the beginning of a retrospective.  It won’t take much time and it will spice things up and set the stage well for your retrospective.

The other game that I played with the team is called the “Ball Throw”.  This game supports the theory of Work in Process (WIP).  I had a larger team of about 12 people (you can probably play with 6 to 15 people) and 20 tennis balls.  The object is to capture the amount of time it takes the team to get all the balls in the done bucket.  The rules of the game are:

  • The same person must be the start point and the end point for the balls.
  • The start person can throw a new ball in anytime they wish.
  • The start person yells “IN” every time they take a ball from the start bucket and throw it in.
  • Each person in the team must touch the ball at least once.
  • Every ball toss must have air time (they cannot be handed to the next person).
  • You cannot toss the ball to a person who is right next to you.
  • The end person (same as start person) receives the ball from the last team member, deposits it in the done bucket and yells “OUT”.
  • Any dropped ball is considered a defect where the person dropping yells “DEFECT”, retrieves the ball and continues on.
  • After explaining the rules to the team, they have 2-5 minutes (your choice) to plan and discuss their strategy before they begin the game.
  • At the end of each round, the team has 2-5 minutes to perform a retrospective on how they would like to improve.

This is one of the most popular Agile games.  It is fun and easy to play and enforces the importance of WIP.  I especially like challenging the team in the 2nd round, telling them they can do it faster and then proceeding to put pressure on them to go faster while the round is in action.  This simulates the business pressure they receive in real life.  You’d be surprised how the defects go up in that 2nd round.  Remember after any game to have a discussion on the parallels of the game to the workplace.  We’ve had some good discussions.

If you’re interested in conducting the Ball Throw Game you can use a spreadsheet that I found online and have shared below.

The spreadsheet allows you to track throughput by clicking an “IN” and “OUT” button for the balls.

Some other resources for Agile Games are the book “Gamestorming” by Dave Gray and the website

Playing the games added another valuable channel for Agile education for the teams and organization.

So have fun and … LET THE GAMES BEGIN!

Cynefin Decision Framework and Agility

cynefin image

I had the pleasure of being one of four Agile panelists answering questions at the Tampa Bay PMI Symposium (good turn out with more than 300 registered).  One of the other panelists, my friend and respected Agilist Steven Granese, mentioned the Cynefin Model.  After that discussion, I felt it would be good to discuss the Cynefin Model and how it supports an Agile process, especially when dealing with complex situations.  So, here it goes …

The world is complex and shows no sign of abatement.  The military learned this as they dealt with different autonomous Al-Qaeda (AQ) cells.  Teams of our military personnel did not have time to contact command to formulate or validate plans.  They couldn’t identify many set patterns because AQ would continuously adapt.  Our military could not be even relatively sure that the same tactical action would yield the same result in each situation.  So, they dropped the silos between teams and departments and opened up communication; empowering the individual teams.  Previous information that was on a need to know basis was now available.  They let their units make decisions, probe with different tactics and then share the learning later on.  This problem area certainly fit in the complex domain of the Cynefin Framework.

Cynefin (pronounced kuh-nev’-in) is a leader’s decision framework developed by David Snowden that aligns things into defined domains.  The framework was developed for knowledge management and strategy, but I believe can assist us in identifying the need for Agile software development.  Cynefin prescribes the way to act on something is based on the domain it falls in.

The five Cynefin domains are:

Obvious or Simple (the known) – We’ve seen this a million times and as such can categorize and respond according to established best practices.  The relationship between cause and effect is well known.

Complicated (the knowable) – Although we don’t immediately know what is happening, we can analyze the situation and come to a conclusion of what must be done.  We can enlist experts to analyze, set up constraints and a process addressing resolution.

Complex (the unknowable) – We’re not able to determine what will cause a particular result. The best course of action is to conduct experiments and check if any or all take us in the correct direction.  A lot of time when human opinion and decision is involved we could be working in this area; simply because humans are complex beings.

Chaotic (the incoherent) – The situation is very unstable.  We don’t have time to experiment or probe since the situation is dire and we need to act.  An IT issue that must be taken care of immediately with no delay may be categorized as such.  If we have no time to figure out a system deadlock issue, we may opt to get ourselves out of this chaotic state by rebooting the server.

Disorder (not determined) – Anything whose domain has not been determined falls into this domain.

Cynefin Table

Image provided by:

The Cynefin Model suggests that we identify the domain type and respond accordingly.  Agile (Scrum for example) is geared to operate in the Complex domain.  The Agile methodology offers the proper Cynefin response to the uncertainty present in many software development projects.  It is inherently adaptive and uses the “probe, sense, respond” method.  Waterfall could handle Obvious and Complicated domain issues, but would fall flat when faced with a complex situation.

Software development offers issues that fall into all the domain areas, but if you use Waterfall you will be at high risk delivering anything in the complex domain area.  If you use Agile, you could have some minor inefficiencies compared to waterfall in the simple domain, but you will reduce or eliminate the high risk of failure in the complicated, complex and chaotic domains.  It seems sound reasoning then if you’ve got any unknowns involved then your software development projects would be minimizing risk by following the Agile methodology rather than Waterfall.

Utilizing “Lean Coffee” for Large Team Retrospectives

Scrum defines the optimal team size as 3 to 9 people.  I’ll skirt by the team size discussion for right now and just accept that there are large teams out there – a couple of which I have direct experience with.  With these larger teams comes corresponding issues; one of which is conducting an effective retrospective.

It is more difficult for larger teams to conduct retrospectives.  It can be difficult to get everyone involved or everyone is competing at once to be heard.  Whatever the issue, the impact is exasperated by the large team size and group facilitation becomes exponentially more difficult.


When we began using a Lean Coffee approach for our large team retrospectives the process became more efficient and effective.  The Lean Coffee facilitation method is usually used to promote learning and I think we’ve put the method to good use in our large team retrospectives.  Take a look at it in the image below and then I’ll continue on to explain how we applied it within our retrospectives.

Lean Coffee

In applying Lean Coffee to the Retrospective, we proceeded as follows:

As in a normal retrospective, the scrum master (facilitator) sets the stage along with gathering and sharing objective data in order to define the focus of the retrospective. The retrospective preparation steps should not be skipped.  If a specific theme is warranted then that would end up being the target of your brainstorm topics in step 2.

Step 1:  Create a simple Kanban –For this scenario, we separated the team into groups (recommend no more than 4 people per group; 5 at the very most) with each group setting up their Kanban as depicted above.

Step 2:  Brainstorm Topics – The topic was to identify what the group felt went well and what we needed to improve upon within the last sprint (no specific focus this time).  Each person independently (no discussion with others) wrote multiple topic themes with one topic theme per post-it.  All of the topic themes post-its were placed in the “To Discuss” column of the Kanban.  We allowed 5 minutes for this step.

Step 3:  Pitch Your Topics – Each individual explained the idea behind any of the post-its that they contributed.  This was done in a concise manner and the scrum master monitored to make sure that nobody was discussing or solving the issue, since this part of the exercise is only to ensure that everyone understands the meaning of the topic theme written on the post it.  We allowed 10 minutes for this step.

Step 4:  Prioritize What To Discuss – Each group member was allocated 3 dots to vote on the topic theme(s) that they thought were most important to discuss.  We allowed 2 minutes for this step.

Step 5:  Manage Flow of Conversation – We determined that we would allocate six sessions of 5 minutes each and would thumb vote at the end of each session to see if we wanted to continue the conversation.

Step 6: Discuss – The topic theme post it with the most dot votes was moved to the “Discussing” Kanban column and the team began to discuss the topic and identify what action items could be taken to ensure improvement in the following sprints, if applicable.  Any action items were captured on the post it.  If we were done discussing the topic theme post it then it was moved to the “Discussed” Kanban column and the next topic theme post it was moved into the “Discussing” Kanban column.

Step 7:  Lock in the Learning – At the end of the last discussion session, we nominated a spokesperson for each group and they alternated sharing their topic themes and action items with the full team.  Time was allowed for discussion.  This step took about 30 minutes and we were able to share and discuss among the whole team 4 “went well” topic themes and 7 “improvement” topic themes (with one topic being a duplicate across groups).  We then took about 15 minutes to record the results and create Product Backlog Items (PBIs)/ tasks to be carried out ensuring action on the identified improvements.

In conclusion, by utilizing Lean Coffee, we were able to separate the large team into smaller groups which later came together to share and educate the whole team.   Separating into smaller groups allowed for better and fuller participation and decreased the usual time needed for the large group retrospective.

Agile Transformation: It’s an Emotional Thing!

Great People = Great Results!  I read it on the banner of the company I work for everyday as I proceed down the walkway into the building.  People are the most important ingredient in the recipe for your organization’s success and people are emotional beings.

If your company is on its Agile transformation journey, there will inevitably be change and change evokes emotion.  Among the possible emotional catalysts are adopting new processes, taking on new roles, reorganizing, forming new teams and the list goes on.  With this change will come many emotions and related actions.

A frustrated person might constantly get angry and fly off the handle at their colleagues.  Their manager may then tell them, “You really have to suppress your frustration”.  The person then concentrates on suppressing their frustration.  They tell themselves, “Calm down – you’re making too much of this – don’t become frustrated”.

Studies have proven that suppressing thoughts only results in amplifying the thought.  Remember the exercise “whatever you do – do not think of a pink elephant”.  The more you try not to think of the pink elephant, the more you do.  So if we ask someone to suppress their frustration then they will most likely become even more frustrated or even angry.

Instead, Harvard scholars say we need to recognize our emotions, but don’t let them hook us.  We should recognize the emotion as a thought and then zoom up above it, analyze it from this high level and ask ourselves why we feel that way.  By taking the time to identify that our frustration may be signaling an important needed action we can then take that action based on our values and not based on our emotion.

If your boss provides you with negative feedback, this will most likely evoke emotion.  If you get hooked by your emotion then you may jump to the conclusion “My boss has no faith in me”.  Instead, it is better to zoom up above the emotion and ask ourselves which of our values will we use to deal with the trying situation. We can speak to our boss with our values of truth, honesty and transparency to better understand their viewpoint and discuss it.

Again, we should listen to our emotions, but base action on our values.  Our emotions change like the wind, but our values are steady and can be leveraged all the time.

Beginning an Agile Transformation at Your Organization: Shu-Ha-Ri?

I attended the Agile Open Florida event in St. Petersburg Florida and the attendees’ organizations there seemed to be split into three camps:

  1. Some teams within the organization practicing Agile and the other teams practicing Waterfall.
  2. Organization just announced or beginning transformation to Agile (2-6 months into it).
  3. Organization been practicing Agile for a year or more (at different levels of maturity).

My perception was that the majority of the attendees’ organizations fell into Group 2 and I would like to expose them and others interested to the teachings of Shu-Ha-Ri and the question of its adoption.

Shu-Ha-Ri is a Japanese martial art concept where the term translates roughly to “first learn, then detach and finally transcend”.  The definition pulled from Wikipedia follows:

It is known that, when we learn or train in something, we pass through the stages of shu, ha, and ri. These stages are explained as follows. In shu, we repeat the forms and discipline ourselves so that our bodies absorb the forms that our forebears created. We remain faithful to these forms with no deviation. Next, in the stage of ha, once we have disciplined ourselves to acquire the forms and movements, we make innovations. In this process the forms may be broken and discarded. Finally, in ri, we completely depart from the forms, open the door to creative technique, and arrive in a place where we act in accordance with what our heart/mind desires, unhindered while not overstepping laws.”

There are some Agilists that believe organizations should practice Shu-Ha-Ri during their Agile adoption and there are others that feel the practice places a damper on the self-organization and empowerment of the teams.  We could debate it theoretically (the scientist’s perspective), but given the audience I am addressing, I prefer to discuss the actions needed to implement Agile within their world (the engineer’s perspective).

If your organization is just beginning its Agile journey, it would behoove you to select established practice(s) and adhere to their guidelines, whether it be Scrum, Kanban, etc.  Teams should self-organize and be self-governing, but I have seen organizations fail because they do not have the sufficient knowledge to implement the practice.  They make too many changes to the established practice too early or are further handicapped because their organization dictates variations from the start.

The best action is to acquire an experienced coach or consultancy to lead you through your transformation. If you cannot do that then learn the Agile practice(s) you have chosen and try not to deviate unless you feel you have the Agile knowledge and process maturity to do so.  It’s important to follow the practice of Shu-Ha-Ri in inverse proportion to the level of Agile knowledge and experience your organization can draw from. In other words, the less coaching and knowledge available to you the more you should lean on the practice of Shu-Ha-Ri.

It is easy for an organization’s teams to fall prey to deviating from a practice too early.  In most instances, newly assembled teams lack the knowledge and maturity in Agile values (ex: transparency). The theoretical argument might be to let the team change what they want from the very beginning because they will ultimately learn and adapt.  The lessons they learn from the experience will make them a superior team and enable them to become a better empowered and self-governed team.  Theoretically, I would agree with this, but the real world can be harsh.  Your poor decisions have a cost and I do not find the world or many organizations to be overly patient.

So, if you want to succeed on your Agile journey, the best course of action is to have a coach that’s been there before.  If you can’t do that then I wouldn’t stray from the fundamental teachings too much, especially before your Agile acumen is grown. If you are forced with early decisions, then your first step should be to refer to the 12 Agile Principles.  I find more times than not that they set the right direction.


Challenges Ahead During Your Early Agile Transformation Days

As promised, I’ll now address two areas that I believe provide challenges for an organization in its early stage of Agile Transformation; even before an enterprise Agile framework is taken into consideration.  Listed below are two of the most challenging areas, symptoms and possible treatments for some of those symptoms.  Each one of these could become a discussion of their own, but my goal is to give the people in the early stages of Agile Transformation some items to look for and address.  I hope it achieves that purpose for you.

Challenge Area 1 – Mastering Scrum Roles, Artifacts and Activities


  • Product Owner (PO) suggesting or assigning tasks to team members
  • PO anchoring and/or influencing team task estimates
  • PO working on other activities (probably related to previous job position duties) to the detriment of backlog completeness
  • Product backlog items (PBIs) are not ready for planning
  • Backlog Grooming/Refinement is not taking place
  • Scrum Master (SM) driving decisions instead of asking questions to lead the team to their own conclusions
  • Scrum Master allows stand up to have extensive conversations outside of the three questions
  • Team members speak directly to the Scrum Master as they answer their three questions during daily stand ups when they should be speaking to the whole team
  • Team members disengaged at Sprint Planning and Refinement (ex: open laptops, not contributing)
  • Retrospective is a “complain-fest”
  • Team members accepting work from someone other than the PO
  • None of the identified Retrospective improvement Items are actively worked and remediated in subsequent sprints
  • Sprints have too long of a time box eliminating urgency


In many organizations as they start their Agile Transformation the product owner and scrum master roles are filled by project managers and managers.  They sometimes can have minimal experience and education about their new role and fall back on previous command and control practices.  The team may also already be accustom to taking direction from them and everyone easily falls into the old command and control relationship.

If you have a Guiding Agile Partner (strongly recommended) then they should be providing education and direction to individuals and to the group as a whole in a “just in time” (JIT) fashion to correct these situations.  Scrum Masters/Agile Coaches can also provide this direction as they mature in their role.  You can also visibly display Agile definitions, statements, etc. on posters or signs related to your more stingy pain points.

Keeping the product backlog in the proper state is the most important activity for the PO.  The PBIs must be prioritized and in the “ready state” before planning or you greatly risk sprint success (see appendix below for definition of ready).  If the PO is too involved in carrying out work related to their previous role (ex: support or troubleshooting) then it will affect backlog quality.  A cross-training PBI to ramp up a team member and allow the PO to shed their old responsibilities is not out of the question.

It is important that the SM is a servant leader.  They should concentrate on creating a successful process and removing impediments.  They need to ask the right questions and foster participation from all team members.  If team members are only making eye contact with the SM during the daily scrum then this indicates that they feel the daily scrum is a status report for the SM.  The SM needs to remind the team that the daily scrum is not a status report and is meant to share and discover information across the team.  A trick to facilitate the correct mind set here is to let a different team member facilitate the daily scrum each day.  The SM cannot allow team members to enter into long discussions during stand up.  I recommend having a parking lot where you list any items needing longer discussions along with a list of the team members to be involved.  After your daily scrum you can choose to discuss them or schedule a separate time to address.  Your daily scrum should not be more than around 15 minutes.  A cute trick that I learned from a consultancy (AgileThought) and that I use to identify the end of the stand up is to announce “Daily Scrum Dot Done” (DailyScrum.done).  This provides a clear end point so the team clearly knows when they can leave or pick up larger discussions.

Everyone has been involved in a lessons learned, post postmortems or retrospectives.  How many of you have spent time collecting feedback only to never act on remediation?  At the end of your retrospective you can have the team “dot vote” and make sure to include prioritized remediation as part of the next or subsequent sprint.  The Retrospective is a waste of time if you don’t act on the identified items. The SM needs to develop techniques to gain full team participation and uncover important items that need improvement.  There is a lot of information out there on different ways to conduct retrospectives and keep them fresh.

Team members cannot accept work from anyone other than the PO.  Listen carefully as you conduct daily stand ups that no team member is working on a task outside of the sprint and the PO’s knowledge.  Nicely call them out if it is the case.

When it comes to the length of your sprint, I would always recommend that in the beginning you don’t go beyond 2 weeks.  This is purely subjective, but I feel that especially in the beginning of your Agile Transformation it will provide you with a heightened sense of urgency for delivery and provide ample time between retrospectives so you don’t move in the wrong direction too long before correction.  If 2 weeks doesn’t work for you then you can adapt and change it.

Challenge Area 2 – Dependencies Within and Across Teams


  • Unable to start prioritized task within current sprint because limited knowledgeable resource is busy on another task
  • Unfinished Product Backlog Items (PBIs) at end of sprint
  • Time spent waiting on other teams in a current active sprint


In the beginning of your Agile Transformation you have done your best to assign individuals in to cohesive, empowered and self-organizing teams encompassing representation across all of your business areas.  An optimal scrum team has all the needed knowledge and skill sets available within each of their team members so that they may successfully complete their PBIs and provide value to the business every sprint.  This is referred to as being “T-Shaped”.  If all of your team members are “T-Shaped” then you have less likelihood of bottlenecks and wasted time.  If everyone is not “T-Shaped” you can estimate the effort to become “T-Shaped” and construct a plan towards this end while minimally sacrificing the delivery of value to the business.  Obviously, you always need to weigh the time burned to do so vs. the gains produced.

You can accomplish tasks and PBIs more quickly if you do not have to go outside of your individual scrum team.  You aspire to this model, however, it is improbable that you will never have to do so.  Before your Agile Transformation you most likely had some silo groups such as database, middleware integration, etc. You have an issue to address if you don’t have enough people to include at least one of those individuals on each team or if the code is not loosely coupled enabling multiple people to easily work on it simultaneously.  Even though you are not yet ready to adopt an Agile enterprise framework, you may be forced to create a separate team that will field all the other scrum teams’ requests for this skill set area.  I recommend you only do this when absolutely necessary because you can very easily abuse this action and end up right back where you started with silo skillset groups.

In some cases, you require dependencies on other teams.  Since you haven’t scaled yet, you will need to have a Product Owner collaboration session on a regular basis so communications are open and prioritization across teams can initially occur until you adopt an enterprise agile framework (some may say a Scrum of Scrums, SAFe, LeSS, Nexus, Program Team, etc. – but again we are not scaling yet).  My recommendation is to create your PBIs such that they never depend on another team in order to complete the PBI.  If you have a PBI that depends on another team for completion then separate each set of tasks out into their own PBI with the dependency falling in the middle of the two PBIs.  This is not a published practice and other Agilists may have theoretical objections, but it works for me, resulting in less unfinished PBIs and a cleaner more transparent demarcation of dependencies.

In conclusion, I hope this discussion will alert you towards earlier recognition and remediation of some of the more common challenges during the early period of your Agile Transformation.

“Discussion Dot Done” (Discussion.done)!  🙂

Appendix:  PBI “definition of ready” from the book Essential Scrum by Ken Rubin.

PBI Definition of Ready

Agile Transformation: First Step

Let’s face it – there is no specific step by step map to follow for your organization’s agile transformation. Every organization is a unique and complex configuration of people, culture and practices.  As IT professionals we seek an orderly set of specific rules to follow, but I’m telling you based on my experience there is no exact plan that you can follow.  The Rational Unified Process (RUP) which I consider to be one of the first popular iterative methodologies in the late 1990s had difficulty getting initial traction because a majority of early adopters took the published process and tried to implement every single step it described.  Only those who recognized that the process needed to be configured and that they needed to pick and choose the actions for their specific organization and initiatives were able to have success.

So in order to successfully transform our organization we must first start the loop of receiving/eliciting FEEDBACK and ADAPTATION.  As in a sports game, there are many factors that are going to be constantly changing.  You receive feedback, assess the situation and adapt to win.

So where there may not be a step by step guide on how you can transform your organization, the good news is we can provide guidance from our experienced situations, challenges and successful adaptations.  My hope here is that I can share some of my experiences and provide you with somewhere to begin to assemble or supplement your Agile Organizational Transformation.  Please take them as they are, tweak them, add to them, pivot and hopefully share your successful implementations and/or adaptations.

Grass Roots Transformation:  “Influence your leaders to speak to other leaders who have adopted Agile at their organizations.”

My personal experience has taught me that it is difficult to implement an organizational Agile transformation as a grass roots IT initiative without the support of senior leadership.  I have been a part of development teams that have implemented Scrum and were successful in product delivery only to have later projects dictated to follow a different methodology because of educational, political or a list of other reasons.  Consulting companies I speak with say that they will not undertake Agile transformations for companies where senior leadership is not driving or at least in support of the transformation.  If developers are pursuing a “grass roots” attempt to adopting Agile they should introduce their senior leadership to other company success stories and senior leaders that their leaders can speak with about Agile.  The good news is that there are more and more companies, CIOs and CEOs that are embracing Agile.  More early adopters of Agile are now making their way into influential positions within their organizations.  My current organization senior leaders spoke to several other company leaders and were impressed enough to move in the Agile direction.  I can remember the era when all the CIOs were influencing each other to implement an enterprise financial system package.  I am now seeing the same buzz around Agile.  Do whatever you can do to fan the flame.

Supportive Leadership Transformation: “Organize your teams and focus on delivering customer value.”

Some experts advise to transform everything at once.  What’s worked in my experience has been to create your agile teams at the product level first.  Leave your program and portfolio personnel operating in the same manner until you’ve got your lower level product team structure and process working efficiently.   Once you’ve got the product level working then it will be time to address the program and portfolio levels.  The strategy in the way you embark on your agile journey will be strongly driven by the experienced individual or entity guiding your organization.

In the beginning, how you assemble your organization on a managerial and reporting level is something your organization will have to decide and will probably be determined or at least influenced by existing cultural and political conditions.  No matter how you initially decide to organize on an HR and managerial level you must form Agile Teams horizontally across your traditional IT organization. Your HR and managerial structure will be responsible for the career progression and performance of their people.  Each Agile Team will be responsible as a team to deliver the agreed upon value to the business.  When creating your Agile Teams do your best to put the correct people together on the team that can get the job done and limit dependencies on other teams as much as possible.

To do this first identify the business groups you need to support and then identify the corresponding product owners and/or executive sponsors that will represent these groups.  Select the proper people across the skill sets to be on the teams necessary to support each business group.  The product owner and/or executive sponsor now become the entity prioritizing the work to be done for this business group.

If you are currently in a traditional IT organization then you probably have requests coming in from all directions.  Business people roll their eyes and blame IT for the long waiting period to address their request.  Perception that you don’t accomplish much abounds.  The truth is that IT has limited people and resources for all the requests and realistically some will never be completed.  The best way to get out of this situation is to have the product owner and/or the business sponsor receive and prioritize the requests.  If the AP Administrator wants a new report then they request prioritization from their own business organization and not IT.  IT should do the work, but the business will prioritize their own work.  This means no longer are IT the “NO people” and I can tell you that this alone will make a big difference in how you are viewed as an IT organization.

As you begin your Agile transformation, your organization should secure a strong Agile Coach.  This person or guiding entity needs to have the ear and work with your highest executive level.  They will need to work with all of leadership and the Agile Teams and provide guidance and education on a “Just In Time” (JIT) basis.  In my mind it is crucial to have the right guidance as you begin your Agile journey.  With their experience, they will recognize your organization’s pain points and challenges to becoming successful and will address these in priority order as you start to adopt the practice of continuous improvement.

So we have now come full circle – FEEDBACK and ADAPTATION.  As you continue your Agile journey you will recognize things that you want to change from your initial structure, process, etc.  My current company has adapted organizational structure improvements three times in the past year.  You don’t need to get things perfect from the beginning.  Again, feedback and adaptation.

Below is a summary bullet list of considerations for guidance:

  • Gain Support and Involvement from Senior Leadership
  • Enlist Agile Coach Expertise Working Directly With Senior Leadership
  • Create Agile Team Structure Within Your IT Organization
    • Pay particular attention to delivering value at the product level first
    • Define structure best you can – you may have to change it again – ADAPT!
  • Concentrate on delivering business value

Remember:  Feedback and Adaptation to continually improve your transformation!

In the next post I would like to examine some of the challenges you may run into during your initial Agile transformation period.