Facilitating Effective Stand Ups

Daily stand ups are usually conducted in the morning, although sometimes occur later in the day particularly when there is a distributed team involved, and this often means that team members arrive unprepared to share what they have been working on. It may have only been 16 hours earlier that an individual was focused but it takes time to get the brain moving and the creative juices flowing.

I have facilitated thousands of daily stand ups and there are a few things that occur during a given project, almost without exception, that need to be addressed and ultimately resolved.

Arriving Late.

The daily stand up meeting has a start time so that time is not waste, and that is the top priority for a scrum master – eliminating waste. If the team is left waiting for a someone to arrive they are left waiting, impeded by the uncertainty of that persons attendance, as a scrum master it is important to address the negligent party and appeal to their conscience that they are wasting multiple people’s time. It is a matter of respect and value that bonds a team with the level of cohesion required to deliver quality outcomes.

If an individual is not on time, continue ahead as scheduled and do not stop or become distracted if they arrive mid ceremony.

I have even taken the step of locking the door on a completely glass office so that when the repeat offender arrived and found they could not get in, it really hit home how disconnected this individual was to the team and that corrective behaviour should be considered for the good of everyone.

Laptops and Other Devices.

Nothing says, “I respect and value your contribution to this daily ceremony”, like hunching down into the glow of a screen while other people share with the team. Frantic typing is also not a great indicator that you are listening to your fellow team member.

Playing games on your phone like Candy Crush Saga equally not a respectful stance to take when other team members are listening and collaborating to deliver desired outcomes.

Come Prepared.

This last one is a given but often people arrive unprepared to share with the group and frantically search their memory for what they did 16-24 hours earlier, or take over the sprint board to remember where they were at 5pm the day before.

By coming unprepared to a discussion you end up spending the time when you should be listening to others, thinking about what you are going to say. I’d argue this is as disrespectful as the examples above because you are all set up, distractions aside and ready to listen but you have chosen not to.

Imagine how you would feel if when it got around to your turn to speak and you raised a point already addressed by another member of the team, a perfect opportunity to contribute and collaborate at the time, and saw the look on the rest of the teams faces. They know you weren’t listening and now you are expecting them to actively listen to you?

At the end of a working day simply grab a post-it note and jot down what you did today, what you plan to do tomorrow, and any impediments you would like to raise.

Not only will you benefit from being a confident team member ready to share and unimpeded to listen and collaborate, but you will also get better sleep that night knowing your thoughts and goals for the next day are safely written down ready for you.

Be Willing To Have Difficult Conversations

As the Scrum Master it is your responsibility to the team to eliminate waste. This can come in many forms but when it comes down to people and people’s actions or inactions, the required response is often to have a conversation.

It is easy in the short term to go in guns blazing and demand an end result, but you will only end up “winning” the point and “losing” the respect of the team member you are there to serve. The better course of action is to speak privately with the individual so not to have them lose face among their peers, and to highlight your perspective and the possible perspective of others relating to their behaviours.

Reflection is a powerful and empowering thing that enables and individual to take control, to be self-organising, and grow or simply heal as a valued and respected contributor to the team.

A person’s success in life can usually be measured by the number of uncomfortable conversations he or she is willing to have.

The real “win” is to facilitate the reflection so that the individual in question can arrive at the answer themselves. It may feel hard to do for some, especially early on in your career but it will have a strong correlation in the long run to the success of your career.

Facilitation is a truly difficult skill that allows for a desired outcome to be arrived at without the threat or application of force. To facilitate your team is to serve their best interests as a whole, as a tribe and community working towards a shared goal. Serve well and all will be rewarded.

Team Specific Retrospectives

At the end of an iteration you are probably running a team retrospective with specific decisions defining the goal, key markers, and how the session should flow. It can be all too easy to repeat the same retrospective format over and over, asking what went well and not so well, what can we start doing and what should we stop doing in the following iterations. Before doing any of this though, it is important to investigate and learn the right approach just as you would over the course of a development iteration.

Even in the event you have been leading retrospectives for your team and have a good idea of the history and context of the group, check your assumptions and have another look at the team’s historical record, morale, job satisfaction, and energy relating to the current state of the project.

When working with a team outside of your own take a moment to study their surroundings, where individuals work in relation to one another and how they interact on a day-to-day basis. Appreciate how they operate during ceremonies, what they do and do not do along with what artifacts they maintain and if any artifacts are missing entirely. The information you gather will help guide the team to an appropriate goal, utilising your observations to offer questions to ask around problems the team is facing.

Questions to ask yourself as Scrum Master

  • What was achieved during this iteration, what was committed to at the start of the iteration and how did the resulting outcome match up against the expectations?
  • What factors going on elsewhere in the organisation may be affecting the team?
  • What happened in previous project reviews and how were the action steps of those ceremonies received and addressed?
  • What are the working and personal relationships within the team and how do these affect those involved and those on the fringes?
  • What is the team excited about and what anxieties do they hold?
  • What outcome would provide value to the project sponsor and team members for the time invested in a retrospective?
  • How has the team received and worked with facilitators in the past?

Set a goal

Time is an important investment for a scrum team so it is important to define a goal at the start of a retrospective to gain team buy-in to spending the time reflecting on the most recent sprint.

A retrospective goal should be broad enough to allow your team to think creatively and be open to possibilities based on their experiences and insights. Unlike traditional goals the retrospective goal works best if you do not define a measurable outcome.

Determine what can be assessed instead of what can be addressed. You want to reflect on what happened during a sprint by having an open and honest forum to discuss and bounce ideas freely amongst the team. By focusing on addressing something from the outset you are preventing the consideration of other aspects and directing the discussion.

How long should a retrospective last?

45 minutes per week of work is considered a good starting point, although it is best to use this as a rough guide and not a rule. Look at the team to get a feel for how long the retrospective should last and consider these factors:

  • How long is the sprint iteration?
  • Overall complexity – tech stack, relationships, departments
  • Number of people in the team
  • Level of conflict/controversy

A sprint retrospective is a reflection of the most recent sprint, while a project retrospective reflects on the length of the project and should be afforded an appropriate duration. To take shortcuts on the time allowed is to cheat the results and benefits that come out of retrospective reviews. An hour may be enough time for a sprint review but a project review can require a whole day or longer in some cases.

Preparation

As the facilitator of a retrospective you should spend an adequate amount of time planning, ensuring the logistics have been considered and there is an appropriate set of activities to engage the team for the duration of the ceremony.

Early on it can take as long to plan a retrospective as it does to conduct it with the team, over time this period will reduce but you will never require zero planning. To not prepare at all for a retrospective would mean you’re not thinking about it at all, which is a recipe for failure and a disservice to those taking part.

Facilitating the Retrospective

Outline the structure of the retrospective so everyone involved is aware of the plan, making sure to set aside the largest portion of the session to gathering data and generating insights. Take breaks at logical stopping points.

Encourage equal participation and new perspectives with a focus on the conversation, helping the smaller voices to be heard and boosting the confidence of those perhaps anxious of sharing what might be a controversial contribution.

Choose activities that require team work and collaboration to deliver results and mix things up by pairing off with people in the team that do not normally work together on a day-to-day basis.

Provide paper and markers so that insights can be captured in a highly visible way. Arrange insights on a board for all to see and ponder over throughout the session, ensuring no one insight is diminished because of the quality and colour of the paper combined with the quality and clarity of the marker. I like to use Post-it notes and Black Sharpies, there are enough similar shades of post-it notes to group contributions by colour if needed without a significant contrast and black sharpies are big enough and bold enough to be read from a reasonable distance.

Reflect on the Retrospective

It is important for a team to reflect on the most recent sprint, and it is equally important to reflect on the retrospective. A retrospective focuses on all the ceremonies, artifacts, and interactions included during a sprint while the retrospective itself is easily forgotten as a key aspect of the iteration.

Gaining feedback and insight about how the retrospective has been received and performed will help the facilitator to learn and improve going forward just as we intend to in Scrum. By gathering feedback and acting on this feedback you will garner greater respect and participation in future retrospectives leading to a constantly improving cycle of reflection to help remove waste and accelerate team performance.

What Waterfall Development Taught The FBI Post 9/11

In March 2010, The Federal bureau of Investigation dropped its most significant modernisation project, a project designed to prevent another attack like those on 9/11. The FBI had been trying to update their computer systems for a decade and once again the most recent initiative had failed. Jeff Johnson arrived at the FBI in 2009, encouraged by the CIO, Chad Fulgham, a previous colleague at Lehman Brothers, and now he found himself in charge of clearing up this mess.

Jeff had been Assistant Director of the IT Engineering Division, with a big office in the J. Edgar Hoover Building overlooking the Washington Monument. Despite this lofty position Jeff spent much of his time in the basement attempting to salvage a project everyone saw as already sunk.

After 10 years and hundreds of millions of dollars the plug was regrettably pulled with the decision being to bring the project in-house to be “done and done well”.

The project was a computer system to replace the filing of paper reports in the modern era of Facebook, Twitter, Amazon, and Google. The typical special agent trying to get anything done, from paying an informant to filing a report on a bank robber, continued using the process their peers had been using 30 years earlier. Writing up a document, printing 3 copies; one sent up the approval chain, a second stored in case the previous copy got lost, and a third used to manually index keywords into the database.

Approval was sent in an equally slow and dated process that was regularly blamed for a systemic failure to maintain a clear picture. Analyst’s for the 9/11 Commission couldn’t even get access to the information due to the poor state of the FBI systems, which could not be relied on to scale beyond small groups of individuals. Many factors were identified as to why there had never been a terrorism threat assessment carried out but the report singled out “woefully inadequate” technological sophistication.

The FBI lacked the ability to know what it knew: there was no effective mechanism for capturing or sharing its institutional knowledge.

The FBI responded with Virtual Case File (VCF), intended to ensure the failings of the past would remain there. They had already budgeted $100 million dollars and just needed another $70 million to see it through.

The FBI spent $170 million dollars on a computer system program that was dropped 3 years later before anyone could ever use it. Not to worry, in 2005 the FBI announced Sentinel, a $451 million dollar replacement designed to go live by 2009. All the budget controls and procedures missing years earlier had been taken into account to ensure successful delivery.

By 2010 Lockheed Martin had delivered half the project at a spend of $405 million dollars. Independent analysis proposed the project would require a further 8 year and $350 million dollars to complete.

What Went Wrong?

It is all too easy to point the finger at possible causes like the wrong people or technology, but the reason these programmes failed is in the way people work.

The people at Lockheed Martin spent months preparing to bid on the contract, looking over the requirements and planning the system architecture. They spent months planning how to do the work from beginning to end, producing beautiful Gantt charts to reassure everything would go smoothly.

The Gantt chart laid out every milestone and  delivery date, a complete picture of the future designed to assure the FBI that time, budget, and scope would be met. The problem with Gantt charts it they are always wrong.

No person can predict the future, and with so many possibilities to derail a prediction the odds are that the prediction will be wrong. In the event a Gantt chart is proven right, chance is a wonderful thing.

Gantt charts appeared prior to WW1 and were used in 1910 by General William Crozier, they have since been carried through to modern day project management and unfortunately the stubborn nature of trench warfare and “over the top” tactics remain popular.

Lies and fabrications hidden behind colourful charts may win contracts, but responding to change over following a plan is realistic and will successfully deliver desired outcomes on time and in budget.