Baby RACIs: Keeping it small, keeping it real

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

BIG RACI

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?

brainstorming-sessions

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

Raw

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

Grouped

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.
Cake
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.

agile

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.

 

Shorten your Standup

Standup used to feel like this

Standup used to feel like this

Our team recently made a change that reduced our standups from 30-45 minutes to 10-20 minutes.

I repeat: 30-45 minutes to 10-20 minutes.

I guess the key question is – how did we get up to 30-45 minutes for a standup? That’s kind of a long time to stand around!

Well, we started using standup to communicate status. This is even though we have an automated agile board – upon which status should be communicated.

And when 12 people communicate status, ie what I did yesterday, what I’m going to do today – we lose the ability to really communicate about things that need talking about.

The sad thing was that after we spent 20 minutes on status THEN we would start talking about defects, problems, and blockers and pretty much people would be ancy and not really interested in talking and solving problems.

So we decided to pull it in and nail it down to what really needed to be discussed. This was deemed to be:

Priority Defects – answering: what problems are we facing in our production process/build?

Any problems with functional test/continuous integration – answering: what problems are we facing in the upcoming process/build?

Blockers – answering: what’s stopping me from moving forward?

This approach got us talking about things that matter.

We are now communicating what we need to do, and who is going to do it; quickly. The result of our actions (read: status) is reported in the automated agile technology tool (which is what it’s for).

The key is really to move from reporting (which is past focused) to assigning (which is future focused).

Feels a bit more like this now

Feels a bit more like this now

 

I cannot tell you how liberating this is.

Loving the Devs OR A Little Appreciation and Trust Goes a Long Way

Developers get a bad rap from us IT PMs.

We IT PMs have a sort of prevailing wisdom about dealing with the ‘devs’. We even talk about it in our job interviews as a known issue; this idea that Devs are cantankerous arrogant curmudgeons, and we need to have certain skills as PMs to navigate through Dev incurred roadblocks to timelines.

Well, I’ve worked with and been friends with Devs for a long time and I think it’s time we think a bit differently about them. From what I’ve seen, Devs have always been good to me (made deadlines, stuck to process, built incredible things) when I’ve thought of them, and given them high regard.

I think any PM will see an improvement in Dev-Pm relations if you remember and adapt to the following:

Appreciate The Knowledge

Requirements become design and merge with the human skill of the builder/artisan to become something usable and beautiful

Developers are  like skilled artisans; people who shape, and mold an idea into something concrete, movable, usable. We respect someone who, for example, builds a beautiful table, because we understand that the ability to merge art and function is unique and rare. Perhaps because there is so much work, and so many developers, we tend to down play the work they actually do.

With an artisan point of view, we should approach developers with an appreciation for their knowledge. This attitude manifests itself when we interpret questions around requirements not as stone walling, but instead, a desire to build the best thing possible.

Artisans tend to develop a sense of pride in their creation. We should recognize that when we shift gears too suddenly in requirements, that thing in which pride was taken, has to be tabled. There is some kind of human cost to this, a disappointment. Multiple disappointments can lead to bitterness. As PMs we should recognize this sensitivity. Our role in controlling the process and QAing and ensuring good requirements is key to minimizing this phenomena.

Trust the Delivery

I approach that edge of the full elaboration of requirements and the beginning of the magical transformation into something functional carefully.   As a team, we want to explain the design, but relax and step back slightly to allow the technical ability to form idea into function to show itself and flourish.

I think a lot of PMs have a hard time letting go at this point. We often want to know the exact details of how something will be built. So we have to employ trust and allow the development team to prove that they can deliver. Paradoxically employing trust, even if things arrive a little late, serves to open up the channels of communication about the details.

It’s ok…let go!

I learned this directly from a dev manager when he suggested that instead of questioning why something was done by a certain date, I instead inquire about the complexity of an item. The implication of ‘is this more complex than originally thought’ is that the developer is doing their job. The implication of ‘why isn’t this done’ is that the developer is not doing their job. Subtly of approach respects the individual and lends towards a better delivery.

Give em a say in the Process

Contrary to popular belief, I think most developers actually like process. I’ve worked with dev teams who’ve initially resisted process become dev teams who champion process. The win for the developer is when process produces good requirements, be they requirements documents, or super clear user stories with well thought out acceptance criteria. The other win for process is when the process keeps WIP at some kind of sanity level to allows the developer to do the kind of work they take pride in, and the team to trust the delivery. Monitoring both – clear requirements and scope sanity – will be an immediate win to reducing barriers to process.

Especially when it comes to code migration process, we can really engage developers. Let them create the process while providing guidance that the process should be simple, clear, clearly elaborate roles and serves to ensure traceability. PMs can help by then documenting what the developers agreed to, helping to shore up any holes in the process, and then acting as an oversight on that process. The key is it’s their process, not something that was dropped on top of them.

Course, those three things, appreciation,  trust and communication are the basis of all good human interaction.  PMs, let’s do what we can to make sure that when it comes to developers, we employ these tools to become partners, not antagonists.

 

We Got Spirit, Yes We Do: Project Spirit as a Tangible Thing

I used to think that it was just me.  Like I would go into new project environment and feel like ‘ugh’, the human emotional soup was all gross and thick.   People were so mean on one project that when I tried to bring two representatives of opposing groups together, as soon as the IT rep walked in the room, the business PM yelled ‘WHAT IS HE DOING HERE!?’.

mudslinging

Seriously?! I’m just supposed to have a thick skin?

Is it possible to really have a successful project when there’s nothing but human muck flying around?

I never thought so.  And now a new study suggests that yes indeed, there is such thing as a ‘feel’ to a project…they call it the Project Spirit.  And there’s some data to suggest that a good Project Spirit will result in Project Success.

This seems a little common sense….HOWEVER.  There are still people that believe that a) people have to do their jobs, and b) they have to bone up and have tough skins and not be so sensitive and c) none of this emotion stuff affects how the job gets done.

WRONG – the emotion stuff absolutely does affect the project.. absolutely does.

Here’s more on that…

Project Spirit and Project Success

I like this idea of Project Spirit.

Seems kind of hokey at first, but according the February 2013 PM Journal article “Managing the Intangible Aspects of a Project: The Affect of Vision, Artifacts and Leader PMJFeb2013Values on Project Spirit and Success in Technology-Driven Projects” by Aranson, Shehar, and Patanakul, Project Spirit is actually a thing that can be measured.

Basically Project Spirit is:

  • Emotions
  • Attitudes
  • Behavioral Norms

…0f the project participants.

The article suggests that certain activities, which they call Leader Building Activities, affect the Project Spirit.

These activities are defined as:

  • Vision, and the ability of the leader to articulate a vision that people want to follow
  • Values, and the ability of the leader to instill their positive values into the project team
  • Artifacts, the rituals and symbols of the project

The causal relationship is that the Vision, Values and Artifacts (Leader Building Activities) affect the Emotions, Attitudes, Behavioral Norms (Project Spirit).  FInally Project Spirit affects what the authors describe as ‘Contextual Performance Behavior.’

“Contextual performance behavior involves voluntarily assisting coworkers in various ways, taking on additional assignments, keeping a positive attitude and tolerating inconveniences  at work.  Contextual performance behavior generally has two common themes: It is representative of the employee’s extra efforts that contribute to productivity, and it is not directly enforceable, meaning its is not technically required as part of one’s job

And it’s this contextual performance behavior that can affect project success.

The authors set out to prove that “Project Spirit positively affects contextual performance behavior” by analyzing NASA Mars projects.

HappyLanding

Yea! We did it! (I dig these happy mission control people)

Mars Pathfinder, a succesful project, was one where Project Spirit was managed through setting a clear vision, management that set an example through their own tone and behavior (values), short effective meetings, team happy hours, colocation (artifacts).  The vision, values and artifacts resulted in a team that had a certain sense of excitement (emotions), a commitment to the people on the project (attitudes), and high spirited group of people who valued honesty (behavioral norms).

Mars Climate Orbiter, a failed project, was one where Project Spirit was not managed. The vision was driven by cost savings,

yeaaahhh...ya don't want a failure report after your project

yeaaahhh…ya don’t want a failure report after your project

management “lacked a balance between confidence and arrogance”(values), a sense of the need to build a “protective shield to outside option..or expert involvement”, a leadership that lacked a ‘collegial relationship with team members’, and a team that was not co-located (artifacts).   Emotionally the team was very invested in success (emotions), resulting in an attitude to devote “lives, weekends, and time” (attitudes), and a “diminished culture of inclusion” (behavioral norms).  This resulted in an over taxed workforce who weren’t open to outside input that could guide the project (behavior outcomes).

Bottom line

The project that set a positive emotional tone through clear vision, people-affirming values, project rituals and symbols resulted in a place where people felt excited to do their jobs, and went above and beyond what they were supposed to do, was a clear success.

So yea…it’s not just you! There is a feel to that project, and as a PM there are things you can to do start to change that context and bring in a positive Project Spirit through setting clear vision, instilling positive values and setting up artifacts that build a sense of team.  Read the article for more ideas.

RoslinSide note: I’ve been on a Battlestar Galactica jaunt and if you want some good examples of how to do this, watch President Laura Roslin and Admiral Adama.  They do this really really well.  Adama is always instilling values, Roslin is always insting on rituals to build morale, and together they build a vision to get to Earth.  Somehow they build a positive Project Spirit in a really bad situation.