Scrum Master as a Secondary Role

Switching Hats

Recently I’ve been seeing even more discussions on forums about members of the dev team taking on the Scrum Master (SM) role.  I’m beginning to wonder if the traditional resource managers are creeping their way in to staffing teams.  If you don’t understand the role and the value it can bring to a team it’s easy to just look at hours available on the team and who could be available to do the role. 

Having been an SM and individual contributor and observed others trying this as an Agile Coach, my experience is it only has a chance of being effective for someone who has a solid foundation as a SM and then takes on some delivery responsibility.  Also, I’ve seen it work where the team is an established, high functioning Agile Team and both the SM and the team can clearly identify when the person is switching hats.

First off, often when folks take up the role as a new SM, they have no experience in facilitation, let alone facilitative type leadership.  Why there isn’t more training for SM in facilitation? I don’t know.

The most common problem I see is that when the pressure of delivery grows during  a Sprint or release, the inexperienced SM abandons the role and doesn’t even know that they are doing it.  In the worst case, because they don’t know how to be effective in the role they abandon it on a regular basis, for example the daily stand up.

The other downside of splitting the SM role is that teams and the organization often never see the real value of a SM because they only do the minimum that a Scrum Master does for a team… process and bookkeeping.  If you would stop and make a list of all the things you could do to help the team, such as work on aligning the immediate team / environment and operations to Agile Values and principles, you would quickly have a long list of valuable things.  This can eliminate roadblocks for the team that they will never even have to experience.  BTW, how do you thing Scrum scales in organizations and who plays a key role?

If organizations are unaware of the value of the SM role and they feel they need more ‘leverage out of that resource’, then I’d rather see the SM serve two teams in that role than be a individual contributor and SM for one.  When they master the SM role then they can entertain doing a split SM / individual contributor role on a team.


Is Transparency The Key Enabler of Agile?

Transparency IMO is perhaps the key enabler of Agile. It is at the foundation of building trust, the emergent nature of design and the ability to have effective inspect and



adapt cycles.

I recently experienced a breakthrough with a client that was experiencing discord between the Product Owners (POs) and the Chief Product Owner (CPO) in a large product development effort. The primary source of this discontent was basically a lack of transparency. The teams would find out late stage in their release that there was some fixed timeline commitment that had to be met which then would cause a ‘all hands on deck’ message to the teams. The team would then have to put in long hours and weekends (mini-death march) to try to get the commitment met. As it turned out, knowledge of this commitment could have been shared with the team a few weeks before it was.

Of course we all know how well this type of event works in an Agile environment and you can probably guess the outcome
1.  Heroics to check the box on the commitment
2.  Lower quality
3.  Taxing relationships which erodes transparency
4.  Frustration with and doubt of agile change initiative because leadership isn’t walking the talk..

With a heads up you can be prepared for changes

With a heads up you can be prepared for changes

Turns out that the CPOs lack of transparency had good intentions. There was the feeling that by being opaque with respect to such commitments, the PO felt they were protecting the team. This was because often they were trying to change or shield the teams from the unplanned work. Unfortunately while the CPO had good intentions this lack of transparency actually was having the opposite effect.

Working with the CPO to better understand the cause and effect relationship between transparency and trust, attitude and motivation, there is beginning to be a change in the CPO to be more transparent. Through this progress he is now giving the teams working on the product a fuller and longer view of the coming road, they are better able to navigate bumps and pot holes, even pits.

Humans beings deal with change better when they have a clearer idea of what challenges may be coming rather than being blind sided. They can mentally prepare and even offer different perspectives and innovative ideas with respect to dealing with possible bumps, potholes and detours in the road ahead.

Does ‘Who Makes a Good ScrumMaster’ Have Much To Do With Their Current or Past Role?

Recently I’ve read a few blog posts and forum posts discussing, ‘what role do the best ScrumMasters come from?’

One post in particular suggested that perhaps Technical Leads are the best candidates because they have deep knowledge of the technical domain in which the team is working. In my experience, unless they are already seasoned facilitators, their deep technical knowledge can be more of a hindrance to facilitating a group through a process.  What they need is a deep understanding of the goals they are trying to get the team they’re serving to, the process, and its mechanics.

Too often folks who are Technical Leads and contributors on projects, when made a ScrumMaster without previous real facilitation training/experience, can too easily lose focus on facilitating and get submerged in the technical details. They lose sight of the bigger picture, the process and the overall team.

Let’s talk about facilitation for a moment. Folks in the software community throw around the word ‘facilitation’ to loosely.  When I ask folks how they define it, they have a tough time concisely describing it.  Some suggest that going to CSM certification training teaches people facilitation skills they need to be a ScrumMaster… WRONG!  At one consulting company where I had the honor to work, I received several weeks of group and workshop facilitation training, including skills training, role playing and shadowing experienced facilitators.  In this training, one of the key things we were taught was good listening skills. One gets virtually none of this in any of the Scrum Alliance certifications.

I would worry less about what role someone is coming from and focus more on the skills and experience needed to be truly successful in a servant leadership/facilitation role like a ScrumMaster.  Lastly, you need someone who truly wants to take on this challenge.  I was at a client recently where being ScrumMaster was seen as punishment for having done something wrong… although they never knew what it was they did wrong.  The reason for this perception is that the leadership of this team didn’t understand the role and just saw it as a box to check, and a set of responsibilities to assign.  Unfortunately, the person who got the assignment also still had their delivery responsibilities.  This was a car without the lug nuts on its wheels; they were bound to come off once it started rolling.

Bottom line: it’s what a person’s skills and experience are, especially in facilitation, negotiation and of consultative communication, that matter.  If the person is also a subject matter expert of the domain, technical or otherwise, that is great. I just wouldn’t trade the latter for the former.

Thoughts from the LSSC 2012 Conference – Boston, MA

I just recently returned from LSSC 2012 conference in Boston, MA.  Besides getting my iPhone stolen, it was a great conference.  The keynote speakers were both thought provoking and entertaining.  I especially enjoyed the fact that the presentations demonstrated interdisciplinary thinking.  There was a good balance of reports on the continued successful application of Kanban and Lean as well as extensions to the thinking.

In this blog post I will share a few of the presentations I attended that I found most useful.

First there was David Anderson’s presentation on a systems thinking approach to introducing Kanban.  in his talk, David
pproach to introducing Kanban into an organization.   In brief, the six steps of the process are:

1.  Understand the sources of dissatisfaction within the organization

  • Consider viewpoints of both internal and external stakeholders
  • Identify the source of variability that cause dissatisfaction

2.  Conduct Demand and Capability Analysis – Ideally by work item type and class of service

3.  Model the Workflow

  • Understand the knowledge discovery process by type of workflow

4. Design the Kanban System

  • Be prepared to negotiate on classes of service
  • Let the business folk believe they designed the Kanban System

5.  Visualization of the work

6.  Roll Out Plan – craft a roll out plan that is appropriate and reasonable for the organizational context

  • Consider how to ‘sell’ the new system internally

This process tends to be iterative in an environment / culture that values learning and enjoys continuous improvement.

I was also able to pick up a pre-release copy of  David Anderson’s new book “Lessons in Agile Management – On the Road to Kanban” and from my inital perusal of the book, it looks to be chalked full of applied lessons as well as value added perspectives on current thinking in the Agile and Lean space.  The book is almost certain to educate and amuse its readers.  I would recommend it to those looking to develop organizational agility and what I like to call ‘lean-ility’.

The second talk from the LSSC 2012 conference that I’d like to mention was the one given by Michael Kennedy on ‘Set Based Decision Making – Taming System Complexity’.  This was the second time I had heard this talk but this time I was listening from a different perspective.  There as a great deal of focus at this year’s LSSC conference on learning in systems and organizations and this was what got me listening to Michael’s talk from a learning perspective.  In listening to Michael’s talk it became quite apparent that one of the significant weaknesses we have in software development processes, including agile and lean ones, when compared to the hardware product world, is that we don’t do a good job preserving learning.

Michael Kennedy used the example of how Toyota preserves the learning about ‘how to build cars’ within the companies workers.  This has been a key to Toyota’s ability to produce new vehicles so quickly.  In software development, there is little to no effort to preserve within a team let alone an organization the lessons it has learned over the years.  The mythology of the organization is lost because of reorgs and the view that humans are interchangeable on teams.  There is so much focus on the short term, the next quarter, that there isn’t a longer term perspective where improvement can occur, therefore the short term learning in most organizations doesn’t accumulate much beyond a project.  This is something that needs to change if agility is to progress in software development organizations.

The last talk I want to mention was the one given by Mary Poppendieck entitled “Continuous Feedback: Process Control for Developing Software-Intensive Systems“.  The particular part of Mary’s presentation that got me thinking was on the idea of “whole team – whole problem”.  It really does seem that many organizations have taken the concept of ‘product owner’ from Scrum and recreated a situation where product development as a whole has gotten dumbed down in that the development team now understand less about the domain they serve and the customers within it.  They have become more focused on the ‘how’.  A by-product of this in such organizations is that there also tends to be less ownership of the backlog and commitment to what’s delivered.  A ‘that’s not my problem’ mentality can be seen.  This is a topic that I plan on thinking about further and will have additional blog posts.

If you’re interested in lean and Kanban, I highly recommend attending the Lean Systems Society (formally the Lean Software and Systems Consortium) conferences.  I know I’ll be at next year’s event.

Agiles 2011 Buenos Aires, Argentina – Agile Growth in Latin American

4th Annual Agiles Conference

I write this on my return journey home from Buenos Aires, Argentina and Speaking at the Agiles 2011. This is the fourth annual Agiles Conference. The organizers should be commended as the conference has improved each year according to attendees including Katia Sullivan who has attended since the first instance and was the advocate within VersionOne that landed sponsorship for the conference from VersionOne since the first.

I had just come from speaking at Agile Cambridge and attending the LSSC Lean /Kanban in Antwerp. IMO the Organizers of Agiles 2011 did as good of a job in most area as these other two conferences and in some areas ,they did better.

Jeff Patton - Product Discovery Using Story Mapping

Agiles 2011 started off with a keynote address from Jeff Patton on the “” which was very well received. Jeff’s workshops on the use of story mapping

were very popular. There were probably 3 to 4 times the number of folks that wanted to attend than could, due to the room size the workshop attendance was limited to 30 for each session. This was like dejavue from Agile 2011 in Salt Lake where there was a much larger room, but standing room only.

My favorite talks were Jeff Patton’s keynote and his workshop on Product Discovery using story mapping.

My talk was attended to capacity and seemed well received. My talk was entitled “Establishing and Maintaining Collaboration and Transparency – The Foundation of Effective Teams”. In my session I introduced the attendees to a non-technical tool, Strength Deployment Inventory (SDI), that allows for self-discovery about one’s Motivational Value System and Valued Relating Style. This knowledge when applied and practiced gives members of a team an understanding of not only how to best relate to those with different relating styles than their own, but also why they communicate and behave.

Mike DePaoli speaking at Agiles 2011

SDI looks at behavior from 2 perspectives, when things are going good and when in conflict or facing opposition. It also provides a fairly simple 3stage conflict resolution model which is an excellent tool for team members to utilize to recognize when the Type of conflict they are engaged in and how best to handle it given the style of their opposition and their ‘conflict sequence’.

During my workshop we only scratched the surface of how SDI can be leverage to help foster openness and trust which are the keys to realizing collaboration and transparency. If you’d like to find out more about SDI, visit the website

The conference ended with a party at a club that had been reserved for the event. The party started with a conference retrospective with all who attended the party. This note only demonstrates commitment to Agile, walking the talk, but also to continuous improvement. Kudos!

I hope to have the chance to attend and speak at the conference next year.

Integrating UX into Agile Initiatives

I frequently get asked about how to best integrate UX / UI teams into Agile initiatives, to have them work in a more iterative, incremental manner.  It is frequently reported from UX folks coming from a more sequential development environment that Agile compromises their creativity and their ability to provide a more well thought out user experience.  In my experience feedback in this vein tends to more a reaction to change.  The habit of doing big up front UX design at higher fidelity is not a required required behavior for producing a winning UX. 

The transition for many UX folks can be a struggle, but it’s like any significant change, you can choose to try to do it all at once, big bang change, which is almost certain to be reacted to out of the amygdala in our mammal brain or you can undertake the change in more of a kaizen approach, small changes, measuring effect as you go. The small changes are more likely to keep the person being asked to change rationally involved rather than fighting or fleeing the situation.

UX is frequently a limited resource on teams and shared between project / Sprint teams.  Because of this it’s important to keep in mind flow and the demand for service from their product development team. I’ve used an approach like the RITE (Rapid Iteration Testing and Evaluation, originated at Microsoft) model, where the UX Team works collaboratively with the rest of the team but they divide their time up between the different demands for their service, designing for upcoming sprints, collaborating with other roles on the team during the current sprint and testing UX deliverables of the previous sprint with users. This cycle helps to balance flow and allocation of UX capacity across these 3 essential areas of their contribution to the team effort.

Image From article “Adapting Usability Investigations for Agile User-centered Design” – Desirée Sy

The amount of time spent in each of the areas depends on the team and domain context and can be tuned from observing execution from Sprint to Sprint. I suggest involving the greater team when having this tuning discussion.  This can be an excellent topic to visit during the team’s retrospectives.

Recently I’ve been considering tracking UX efforts in multi team contexts as a separate ‘sub-system’ on a Kanban board to help visualize better the flow and available capacity of this frequently constrained resource. So while there would be a backlog and story board / task board for the overall team working in a, say, Scrum manner, the UX function would track their overall work function demand and provide visualization of it to the organization on more of a kanban board.   I think this could assist in balancing flow by enabling teams to better manage resource dependencies and of couse to enable them to see when they could pitch in to help with some of the design process work where they have interest and or skill when UX becomes the bottleneck (In my experience, not all work UX folks do can only be done by UX folks).

Bottom line, big change is nearly always a challenge with human beings, it’s just the way our brain has evolved and what as kept us alive as a species.  Consider making changes in small increments, measuring the effect and adjusting as necessary.  Also, consider utlizing something like the RITE model to balance the flow of UX service type demand for your context. And lastly, consider using a Kanban board to help better visualize UX work across teams and the available capacity and timing dependencies to optimize flow.

Agile 2011 Reflections and Observations

Agile 2011 – Salt Lake City was a great event. I enjoyed delivering my presentation on Continuous Improvement. I had over 100 attendees and based on the feedback I received, folks got value for their time and some even had some ah-ha moments! It’s always a good sign as a speaker when only 2 people out of over 100 leave before the end of your talk 🙂  I was happy to make use of the ‘Sailboat’ adaptation of the ‘Speedboat’ Innovation Game.  I was able to collect some good information about perceptions of why organizations are challenged with both starting and effectively executing continuous improvement programs.  The only challenge was running the game with the size of the audience.  I could have used a couple additional facilitators.  Lesson learned.

VersionOne put on a fantastic party for customers and friends at the McCune Mansion. It was a 20’s-30’s party with flapper girls and gangsters. Paul and Ian Culling really got into the theme of the party, complete with Tommy Guns.

My favorite sessions that I got to attend was Mary Poppendieck’s presentation on design thinking. It is so true that much has been lost by divorcing those who design from those that build from those that use. The best example was Thomas Edison.

I also enjoyed Jeff Patton’s ‘Telling a Better Story’ presentation. It was truly standing room only. Look for Jeff’ Patton’s new book entitled ‘Story Mapping’ coming this Winter!  Jeff’s wisdom of starting the story telling / writing process at a mid-level of detail is one of the key techniques that makes Story Mapping so useful. I remember using similar techniques back in my OO analysis & design days where we’d model what people or other systems would do to accomplish they’re goals in a similar fashion and then create the abstractions. We’d also role play the objects to balance and give a personality to the objects / components on our models.

Folks interesting in story mapping should also look at the Interaction Design techniques in Alan Cooper’s books. I made use of these techniques while working at AOL and NetApp.

An unfortunate way of thinking about Agile and now Lean and especially Kanban that I still heard persisting was the view of these as an end and not a means to an end. This is indicative of the ‘Silver Bullet’ type thinking that has accompanied software method and tools since the CASE tools of the 80’s.  This type of thinking causes development organizations not to focus on whom they really should be serving, they’re customers and shareholders. It also impedes having a learning culture because most of what is learned and added to a team’s shared experience is tossed out when the next silver bullet is pursued.

Organizations that evolve to the next level learn, those that just quickly try something and when they don’t get immediate success throw it out and move to the next thing, don’t learn. This is especially true when a reorganization occurs with the change, resetting the mutual trust, unity and shared experience of the team.

I hope this type of thinking is on the decline and that by Agile 2012 I hear less of it.

I appreciate and am thankful for all the great minds and personalities there are in the Agile and Lean Community. We’re only beginning to peel the onion of the many benefits these philosophies can bring to the people in the different disciplines that collaborate to create value for those we serve.

I’m looking forward to peeling that next layer as an Lean-Agile Coach and Organizational Mentor.


Observations from Agile 2011 – Day 2

Agile 2011 in Salt Lake City celebrates the 10th anniversary of the signing of the Agile Manifesto.  Thus far the conference has been interesting but somewhat predictable. 

Here are some observations from my experiences during the first two days of Agile 2011:

It is shocking how few folks in leasdership positions seem to grasp the difference between strategy and tactics.  I think this may be a symptom of the incredibly short attention span most have business today… looking at the current quarters performance.  Chet Richards says it well in his book “Certain To Win”, “It is as if corporate leaders believe it is more important to install technology than to understand what to do with it.”

You see this with organizations that want to become Agile but they seem to have a hard time clearly expressing  why they would undertake the changes necessary to transform into an Agile organization.  This pattern I call the ‘Silver Bullet’ pattern.  Chamber the bullet, ready, fire, aim and if that doesn’t kill the current perceived beast, then buy the next one to see if it can  slay the beast, but in the mean time execute a series of reorgs to reboot the org all the while not learning much of anything…sound familar? 

I’ve been looking at the world from a holistic systems and interdisciplinary viewpoint for a while now and from such a perspective Agile software development has always been a complex adaptive system.  This view is generally shared by folks I know and authors I’ve read that also have a systems view of the world. 

What’s facinating is that each year folks just seem to recognize a few more of the dependencies that already exist in this system.  For instance scaling Agile is a significant topic in the market today and as the onion get’s peeled it is becoming more and more clear that the challenges of scaling Agile in organizations is not about process or techology or tools, it’s about the human component, the way our brain architecture  reacts to change which is why change management is needed in the first place.  

Denial of the fact that in complex adaptive systems things just aren’t very predictable can cause fear in many people.  This is the same denial that gave root to the bastardization of waterfall, the focus on following process, micro-management and the wonderously wasteful metrics that attempted to provide the illusion of project control and protection from projects that failed.

It will be interesting to have additional converations and attend other sessions to see how the lean thinking  (which is more systems thinking-oriented with it’s attention to the whole value flow) onion is being further integrated with Agile approaches.

To Sprint Zero or Not

 Recently I have been seeing posts on a few forums about the concept of using a Sprint zero in Scrum or stabilizaiton sprints.  Too often, the response from the mighty CSTs on high is “that’s not Scrum”  This response makes me think of one of my favorite lines from the 1983 film Trading Places with Eddie Murphy and Nick Nolte.

“Religion is a fine thing… When taken in moderation”

This includes Scrum. Who cares if having a Sprint zero or a hardening Sprint is or isn’t in the gospel of Scrum, if doing a Sprint zero works and you get predictable delivery in terms of timeliness and quality, that is what is important. Having a Sprint zero is only compensating for the level of maturity of your Product Management group in its ability to deliver requirements to a iterative, incremental executing development team. You have to deal with where you are today and not hope for people to change overnight. I work with teams that execute the lean concept of “continuous flow” and it was not easy for their product management to change over to filling a work queue JIT.  There were some intermediary steps 🙂

We should be striving for outcomes, not following religion. I treat Scrum as one more tool on my Agile / Lean tool belt. Scrum like all other things that survive needs to adapt and evolve. Context is the master of application when it comes to process. Luckily you do see a recognition of this by some in the community.  Perhaps the best example is the infusion of Lean thinking  and concepts from Kanban making their way into practioner’s tool belts.

An essential quality of your team and your coaches is that they THINK and not follow an industrial recipe. Don’t get me wrong, I think Scrum does a good job scipting the basics for a significant change. Scripting the basics, IMO, can be very important for executing a significant change in an organization where there is no discipline around the fundamenal process, skill and role changes.

That said, if a team comes to the point of planning a Sprint and the PO is not quite ready, what do you do… Throw a tantrum and say “you’re not following Scrum” and refuse to move forward until they do, or, do you gain an understanding why, educate, re-plan and execute the adapted plan… As an Agile / Lean Coach, I and in my experience, C-Level folk, prefer the latter.

Reflections on LSSC Conference 2011 – Long Beach, CA

The LSSC continues to be a very open and passionate group about educating folks about Lean principles and practices and Kanban.  I find this group to have many more folks that think in terms of Adaptive Systems Thinking and taking an inter-disciplinary approach when approaching software and systems development than in the purist Agile Communities. Quite refreshing! 

That said, there was some “agile bashing” going on which I don’t subscribe too.  IMO, LSSC members need to keep an open mind and treat Lean and Kanban as tools for their professional tool belt that can be applied where the context is appropriate.  This openness will prevent the rise of zealots in the space that can prevent the group from thinking and allowing principles and practices to organically evolve as learning occurs.  

I heard some folks at the conference talking about Kanban and they made it sound like all you needed to do was put up a board and things just worked.  In my experiences it’s not that simple.  The concepts of Kaizen and Kaikaku were thrown around alot, but sometimes I wonder if everyone was really clear on their meaning.  I find it interesting that folks will say Scrum is ‘bad’ but then talk about Kaikaku.   IMO, implementing Scrum is more Kaikaku (transformation) then just implementing a Kanban board.  And from a change management approach, frameworks like Scrum can effectively ‘script the critical moves’ which Chip and Dan Heath point out as being critical to change in their book “Switch”.  Much what determines the right moves for an organization depend on its context.

There were some very thought-provoking keynotes given by Dave Snowden and Chet Richards.  If you are a member of the LSSC, look for the videos of these presentations to be posted soon on the LSSC website.  I highly recommend joining.  I especially liked Dave Snowden’s explanation of the woes of our current educational system, that we have been and continue to be growing a generation of “industrial recipe followers” instead of true “chefs”.  This metaphor hit the nail in the head.  You see this in the behavior of management in organizations to not think about problems or think about learning from failures and improve but instead pursue buying another process / silver bullet.  We need to stress that failure only has no value if one doesn’t learn from it and to learn from it we need t be thinkers not recipe followers.

There were a couple excellent experience reports that really showed how the use of Kanban really did help large organizations improve where Scrum did not work for them. It would have been beneficial to have more information on exactly how the Scrum based transformations where introduced and run to provide a more balanced perspective.  I usually find that the failure occurs because of a lack of understanding of change management and teams only picking the practices that were more comfortable for them rather than using the basics of the framework. 

I had several excellent conversations with Alan Shalloway, David Anderson and other thought leaders in the Lean / Kanban space on practical application of Lean / Kanban for teams that are currently trying to practice some flavor of Agile.  Also, there was quite a bit of discussion in the halls about where Kanban is not as applicable.

Frode Odegard’s presentation “Beyond Lean Value Streams: A Systems Approach” was quite thought-provoking.  It gave an overview of the Lean Software Institutes (LSI) five-dimensional model of business systems and showed how it can be used to implement Kaikaku to create transparency at multiple levels and enable substantial performance improvements 

I participated in the product show case for VersionOne and observed several other vendors visualization tools for Kanban boards.  From what I can tell, LeanKit is the only vendor that seems to be thinking in terms of how UI design needs to evolve when you consider tactile interfaces.  Very soon we’re going to be seeing large tactile interfaces like you see on TV shows like Hawaii Five-O and the CSI shows become economical for companies to utilize for visualization.  (Did you know you can get a 42” touch-enabled LCD monitor from HP for $1800? )  This type of technology will be a game changer for distributed teams being able to use virtual boards.  If you want to get an idea of what will be coming in the not too distant future, watch this video called “A Day With Glass” produced by Owens Corning and start imagining 🙂   Pay special attention to the scenes in the work setting.  Imagine a Kanban board with the abilities shown in the video… Like VTC overlaid with the board.

LSSC11 ranks up there as one the top 3 conferences I’ve attended during my career in terms of learning and thought exchange.  I’m looking forward to next year’s event in Boston, May 13-16, 2012.  Hope to see you there!

Lean-Agile Leadership - Exploring the Creation of Fertile Environments and Culture for Lean-Agile Software Development


Lean-Agile Leadership - Exploring the Creation of Fertile Environments and Culture for Lean-Agile Software Development

The Agile Horizon

Lean-Agile Leadership - Exploring the Creation of Fertile Environments and Culture for Lean-Agile Software Development