Using Agile Tools Beyond the Office

Right now I’m using a google doc to manage my budget – I know – its sooo not  But anyway..

I’m really encouraged by this kid who is treating his whole semester as an iteration and has created a Kanban board that that feeds user story cards for all of his upcoming papers and labs onto the board based on a due date.  He’s got a query on his board so that he only sees cards on his Kanban board that are upcoming in the next seven days.

At the start of each semester he basically has a personal planning session where he inputs all of his due dates from his college syllabi as user stories.  He tags them and gives them dates.  Then, he’s off and running.

He’s even using his Cumulative Flow diagram to see where he might need to plan extra time to do work.

I’m so used to living in Rally and Jira on a day to day basis that I hadn’t really thought about transitioning my live into one of these tools. It makes sense to do so, I already have the knowledge.  And both Rally and Jira have free editions.

And my life needs this – I’ve got to move this year and plan a wedding.  I think if I don’t do this, I might lose my mind.  I’ll let you know how it goes.

In the mean time – watch this video and marvel at the ingenuity of youth!


This is my brain on agile OR help me I can’t shut it off

Agile is changing my brain.

I didn’t think that was possible after 40, I mean isn’t science telling us that everything is hardwired by 21?

I realized it in a church committee meeting the other day.  A leader in the committee is stepping down. So, the question now is – who is going to be the next leader?  Good question, groups need leaders Blue-brainright? But before I started thinking about who that person could be, my brain got all counter- cultural and I blurted out “Why do we need a leader, can’t we just self-organize, or maybe just rotate leadership?

Some people agreed, some didn’t.   We talked some more. And then we started talking about developing our agenda document, something that has lots of updates, and takes some time to build.  And again, my brain was like on some agile questioning trip and I blurted out, “Why do we have to do this documentation? Seems like overhead to me.  Can’t we just get a trello board, put up some cards and have the leadership check in on the cards?”

So now..some folks were looking at me funny.  I understand.  It was I who two years earlier gave a lengthy presentation to the same group of people on the importance of creating a project charter.  That was about a 1.5 hour talk on creating a document.  So now…here I am pushing for no documentation?

Then…then…I started asking about our mission.  I asked to see the vision statement. I asked the pastor to explain it.  I then stated that our team should have a say in developing our vision, that it should source democratically from within the group as well as from church leadership and I think I said (probably a bit rudely too) something to the pastor like “Well, we need to be involved in developing this vision with you.”

Yeah, so, I’m having a hard time in my real life (not at work – real life )

  • not breaking things down into minute chunks that can be accomplished in a few hours   i.e. – not Costco, but onesie twosie trips to the grocery store, every other day.
  • not expecting all leaders to collaborate i.e. – assuming that leaders need to work collaboratively with the team (as good product owners should right?)
  • not assuming all teams function better when they self-organize – i.e. maybe we don’t need that council president
  • questioning the need for documentation and extra process overhead everywhere – i.e. “No I’m not giving to that charity, they want paper checks for goodness sake.  That means half of what I’m giving them is going to processing.  When they reduce overhead…then I’ll give.”

But what’s really scary but also kind of cool ….. I’m getting ok with ambiguity.  So with the same church group, we are still figuring things out.  We don’t know what the future will really look like.  We haven’t picked a new leader yet, we’re thinking our process and mission may change significantly…nothing…nothing feels solid right now. But, since we have the next iteration…er…few weeks planned out, I’m ok.  Shrugging it off.  We’ll figure it out.

This is my brain on agile







Scrum “Master” Has to Go

Scrum Master has to be the most un-Agile term.

I mean really what do scrum masters do?


  • Facilitate dialogue, brainstorming, interactionfacilitator
  • Demonstrate good positive people behaviors like cooperation, lack of blame, fact based conversations and encourage the team to do the same
  • Manage team adminstrivia like updating systems (or bugging/reminding their teams to do so) or handling reporting up the SAFE chain
  • Provide top cover aka removing impediments and preventing distractions

Mountain Goat software describes the role like this:

The ScrumMaster is there to help the team in its use of Scrum. Think of the help from a ScrumMaster as similar to a personal trainer who helps you stick with an exercise regimen and perform all exercises with the correct form. A good trainer will provide motivation while at the same time making sure you don’t cheat by skipping a hard exercise. The trainer’s authority, however, is limited. The trainer cannot make you do an exercise you don’t want to do. Instead, the trainer reminds you of your goals and how you’ve chosen to meet them. To the extent that the trainer does have authority, it has been granted by the client. ScrumMasters are much the same: They have authority, but that authority is granted to them by the team.


He’s a master: “These are not the developers you’re looking for”

The pervading wisdom, common knowledge says that Scrum Masters are ‘Servant-Leaders’ who ‘Carry Water’ for their teams.

Further, Agile is all about Self-Organizing teams with flat hierarchies, where team members are encouraged to be accountable, to work together to determine the path forward, to take work without being told to. They are groups of self-directed people, not without leadership but not with total command and control.

So why, why, in this world of Servant-Leaders who Facilitate and Bring Water to Self-Directed teams do we still use the word scrum MASTER?

Master has all kinds of connotations and I can only think of one that’s positive. Here’s my list:

Master Negative Connotations

He's a master: Totally not trying to be on his team. "And WILLLLL update jira!!!!"

He’s a master: Totally not trying to be on his team. “And now….you WILLLLL update jira!!!!”

  • Master and Slave as in the American Slavery Experience
  • Master and Servant as in the English Aristocracy Experience
  • There’s another one bought on by the acronym SM but this is a G rated site and I’m not going there

Master Positive Connotations

  • Someone whose skill is at a superior level

The positive connotation doesn’t really fit in our definition of scrum master. If it did, then we’d be saying in effect that scrum masters were people who are incredibly skilled at scrum. Yet scrum is agile and should be open to the input of a self-directing team. So even if I master our scrum process today, that doesn’t mean that after the next retro I’ll still be the master of that process.

But I don’t think that’s what was intended with the word scrum master anyway.


He’s a master: “Have those unit tests complete when I return from the hunt.”

I think what was intended was probably to step away from the term Project Manager and invite the idea of something of a call player from Rugby, which is where the ‘scrum’ term originated. But I can’t find a ‘scrum master’ role in Rugby, so I’m really not sure here. I’m guessing. Maybe someone can inform us in the scrum lore as to why we all call the scrum master the master.

Anyway – The negative connotations of master are enough to throw the term out the window. A slave master?  Sorry – I’m not gonna be part of that process. An English Lord, well maybe, if I could live in Downton Abbey.

Master is not the energy we are reaching for in scrum or agile.

People, can we get a new term here?

Here are a few suggestions:

  • Team Facilitator
  • Team Mediator
  • Scrum Coach

I’m sure there are many more. Feel free to post them here or on twitter.

But seriously, scrum master – that’s gotta go folks.

Baby RACIs: Keeping it small, keeping it real

I’m not sure how many of us actually use RACIs.


I’ve found that using the RACI in a project charter (or the beginning of project)  inventively results in it being so very high level that its not really about solving problems, its about elaborating spheres or domains of work. This is good for the start.

Poor Ball – Clearly has not been Consulted about his role in the game. Somebody should tell him…..

However, once you  really get into the project, people start bumping into each other.  Some things don’t get done or communicated. Emotions get frayed and then eventually that results in a situation where people want to do a BIG RACI where they sit and solve communication problems by bringing all parties in the room and working through how things fell through the cracks.  These sessions usually start with someone coming with a huge list of tasks along with a lot of people, so therefore the RACI is BIG.

These BIG RACI meets can become massive blames sessions, so I’m not a big fan of doing a BIG RACI.


baby raci

What I’m finding is that using a targeted baby raci can pinpoint problems, zeroing in on just the small amount of people and few tasks needed to remove a communications blocker and or clarify who does what, to get the team moving again.  This is really a MVP (minimal viable product)  approach to RACIs- meaning do the smallest amount with the least of amount of people to solve immediate small problems.

For example, UAT seems to be a place where things can get confusing.  Its also when the project is getting ready to go live, so a lot of new players enter which makes communication channels explode.  A RACI done at the start of the project may have said something like this:


Task QA LEAD PM Product Owner UAT Testers QA Testers
Quality Assurance
Perform Functional Tests     R   A    C   I    R
Manage UAT     C   R   A  R   C


This is good to start.  But then when you get into UAT it gets complicated.  Maybe there’s office politics about who can talk to whom.  And then there are the QA leads and offshore teams that need to be started/stopped and perhaps a vendor who needs to drop to the UAT environment and then the infra guys who control the UAT environment and before you know it – somebody is mad at somebody.

Babies are cuter anyway

Babies are cuter anyway

At this point, take the people responsible and accountable only.  Try to keep it small and work out a baby raci.  In this example, the problem is that the ‘managing uat’ task above has really exploded into a bunch of very detailed tasks.   For baby racis I think that its good to get super specific on these tasks because usually the specificity will surface where the confusion lies.

Doing a baby RACI could look like this:


Task QA Lead Infra Lead BA PM UAT Testers QA Testers Product Owner
Quality Assurance
Creating Test Scenarios  A  I  R  I  C  C  I
Creating a UAT Test Plan based on the scenarios  R  I  C  R  C  I  A
Communicating with users on a daily basis about their findings  C  I  R  R  C  I  R, A
Troubleshooting their Findings  A  I R  R  I  R  I
Scheduling pushes to Staging and Production with Release Management  C  C  I  A, R  C  C  I
Halting a release date to solve UAT issues  R  C  I  R  C  C  A
Communicating decisions about UAT with The Vendor  R  I  C  R  I  I  A, R


And then…you’re done.  Just stop there with the baby raci.  No need to figure out the full gamit – just solve the issue at hand.


A Church Does the baby raci

Another team that does this well is my church.  I’m on a team that helps with administration and I’m not sure how the pastors learned about RACIs but we use them really effectively.  Basically if there is a new mini-project the pastor will send out the following type of message:

To: All Teams

Fr: Pastor

Subject: Some Improvement we need to do

Body: Hi folks, we are going to do ‘improvement a’.  After discussion we feel that this is the best RACI for this project:

  • Person A – Accountable
  • Person B  and Person C – Responsible
  • Person D, E, F – Consulted
  • The congregation – Informed


Baby raci guidelines

Give it a try.  Next time you have a block in your project, and people are confused and getting angry, try to take an hour or less, get a few people in a room and whiteboard out a baby raci.  Some guidelines:

  • R&A Only: Include only the Responsible and Accountables to build the RACI.
  • One Area: Focus in on one problem area, not the whole project.
  • Specificity is key:  Be very specific in the tasks.
  • No Blame: Careful not to get into the blame game.  Try to keep people focused on the tasks to solve for past failures, but not on the emotion and frustration of the past failures.  You may want to lay the ground by saying something like ‘We are going to focus on clarifing what needs to be done and understanding our relationship to the tasks.  Things may have gotten dropped but this meeting is to figure out, as a team, how we can help each other do these tasks effectively, not to blame each other about the past.’
  • Confirm: Share with the Consulted and Infromed after the meet for confirmation before you make it official.


One way to bridge the gap from raw requirements to user stories

I’ve been on two Agile projects now where the following has worked.  Not perfect but it helps to solve a problem that I’m seeing a lot at the beginning of projects. That is, how do you get from raw requirements and use cases into INVESTic user stories and epics?


Think – you’ve got a new product, you’ve got stakeholders in the room; they are brainstorming.  They come out with a bunch of requirements.  They leave.  The dev team now has to figure out how to take this long list and turn it into develop-able requirements.  We’ve got a lot of tools for dealing with stories once they are baked; estimation sessions, planning pokers etc.   But the tools don’t seem so clear when you are trying to make sense of requirements at the inception of a project.  So here’s one way I’ve seen that works:

Assuming you’ve got that list of requirements I mentioned earlier:

Move requirements into Features


Analyze the requirements as follows:

  1. True Need Analysis – Figure out what the real requirement is behind the ask.  This is usually the domain of the BA. What is the user really asking for?  For example, they may say they want a button that says ‘eject’ but what they really want is a workflow where they can stop the process at any point.
  2. De-Duping and Current State-ing – Figure out what requirements are really mimics of each other.  For example, one user asks for an ‘eject’ button while another asks for a ‘Stop Process’ button. Merge when possible.   Also – it could be that you’ve already built what the requirements are asking for – your current state meets the need.  So give the requirements a current state pass as well.
  3. Grouping and Aggregating – How do requirements  logically fit in with other requirements? What requirements are similar enough that they could be parts of the same feature in a product?  Spend some time grouping those requirements together and give that feature a name.
  4. Acceptance – Determine how you’ll know that you’ve accurately completed this requirement. Check the language of the requirement because sometimes the requirements themselves can become acceptance criteria.
You’ll come out with a not fully baked list of features which you can go take back to the stakeholders for verification.

Prep the Features in a Spike


To fully Prep requirements, create a spike.

What is fully Prepped?  It means that the feature has documented and clarified use cases, user personas who will verify that the feature meets their needs, high level technical specifications if needed, definition of done (preferable with acceptance criteria), and a priority as provided by the Product Owner. Basically it answers what we’re building, who we are building for, how they will use it.

Handover the feature to the development team 

Usually this is accomplished through a separate spike meeting, with a presentation of the findings. Following the handover, the dev team should be able to breakdown the feature into epics and stories and the (currently well documented and doesn’t need to be rehashed here) Agile process takes place.
How are you handling this move from raw requirements into epics and stories? 

It’s a state of mind: Some practical indicators on doing agile vs. being agile

Over the past few years I’ve had the opportunity to work on many teams that call themselves agile. While teams can do the agile process, they may not have an agile mindset. 

An Agile state of mind

I’ve always held out that agile was a state of mind moreso than a process.  More allowing porous flexibility, than stories and iteration planning.  As  PM transitioning from iterative to agile, it’s been a bit bumpy for me.  I’ve wanted too much process, or perfection in documentation – or even too much standardization.  Allowing for being agile can feel chaotic (though as an aside, allowing for a bit of chaos is probably  where Project Management should be heading ).

I think it helps to re-read the original agile manifesto. It doesn’t talk about user stories, or iterations or task estimation. It talks about a mind set – a mental approach, and a set of values.

I thought I’d share my learning with you.  So as a PM, you can have some practical indicators of where your team is with this whole agile mindset thing.

Here are some things a good agile team does:

1. Finds the root cause

AGILE:  When a problem presents itself, a truly agile team swarms around the solution. They figure out the problem and then prioritize it. Because they believe that software should be consistently workable, they almost take it personally when it’s not. So they really want to know why something is not working and they spend time to figure it out.

NON AGILE: Non agile teams tend to initiate surface fixes and then save the root cause analysis for a later time. They are not as passionate about finding the root cause.

2. Questions process and documentation

AGILE: Transition to true agile from iterative was a bit of a challenge for me as a PM. I had to get used to people making me justify why something should be documented. Truly agile teams know the difference between documentation that will sit on a shelf and documentation that will help build great software. And they police themselves, and their leadership, to make sure they don’t waste time.

NON AGILE: Builds in on the shelf documentation into the process because they believe they have to do the work. In other words, they don’t really question authority in this regard.

3. Doesn’t update jira/rally/asssembla that well

AGILE: Another pain point for me, which I have accepted will always be a pain point as a scrum master, is that status updates to story tracking systems is going to be light. I cannot tell you how many times I’ve commiserated with other scrum masters on this point. Better to just accept it and send out the weekly/status – please update your stories/points email.

NON AGILE: Focuses a lot of time on status reporting. Tends to fill out all the fields in the story tracking system. Tends to also then assume that an status email/report must also be filled out.

4. Wants product owner approval

AGILE: Agile teams hesitate if you suggest that you just push code without PO approval. A good agile team trusts, respects and wants the approval of the PO – because that enables them to produce a good product. This is part of the process they actually want to stick to. Even if a release is held up, the agile team will wait for PO approval; schedule be damned.

NON AGILE: Non agile teams tend to push code according to a schedule. The PO had better get on that schedule or they will miss the demo opportunity. In other words, schedule trumps PO approval.


As Thoughtworks empahsizes so well, it’s the difference between Doing Agile and Being Agile

As thoughtworks empahsizes so well, its the differnce between Doing Agile and Being Agile

5. Handles changes without a lot of theatrics

AGILE: Change is welcome. There’s a positive inclination to take a minute and be open, respecting the change as legitimate. This team believes that change is ok – so they have a process built already for efficient processing of changes, and they throw the change into that process.

NON AGILE: Non Agile teams have a process that slows the review of the changes. It’s not an immediate understanding, review and prioritization. Instead you’ll see a change go immediately to backlog. The backlog then grows and grows until no one understands or remembers why something was put there. Then the theatrics begin with the client, who is wondering -> what happened to that thing I asked for – I’m still seeing this bug?

6. Gravitates towards bite sized chunks

AGILE: Agile teams don’t accept large chunks of work. They will scrum around something big and break it down into small chunks.

NON AGILE: Breaking down a task means a) that you can hide within it and b) other people can’t pick it up. So non agile teams accepts a large chunk of work and won’t try to break it down.

7. Consistently tries to figure out how to make things more efficient

AGILE: Agile teams ask the question; how can we be more efficient, faster, more productive. They tend to revisit infrastructure, metrics on systems and incorporate automation into the process (like build servers and CI).

NON AGILE: Tends to revisit infrastructure, efficiency, metrics questions when things stop working or slow down to a crawl.

An Agile mindset is just that – a state of mind, a set of values. Its a constant questioning, and an opening up to possibilities. Its a predisposition to produce great things.

Take some more time with this presentation from Thoughtworks.