by ·Comments Off on Agile Book Reviews

Book stack imageOver the past couple of years, I have made the time to seriously read books within the Agile domain. I have been surprised by both the number of books available and the variability in their quality.

I read Agile books to broaden my knowledge and learn from the experience of others. For each book that I read I wrote a short review and have given a star rating. This was primarily to help the Agile community of practice I was with but also to help myself remember what I have read.

I have created a new page on this site to list all of my book reviews, these are books that I have read thoroughly cover to cover. They have all been bought, downloaded with Kindle unlimited or electronically from another site. I have not received any compensation and I am not sponsored in any way. I have included clickable cover images to Amazon just in case anyone wants to buy a book immediately or see reviews from other people.

The reviews contain my honest and personal opinions, it’s fine if you don’t agree – there are many more reviews on Amazon so please take a look there.

To see the reviews please select ‘Agile Book Reviews‘ in the side bar or menu or click here.

And to answer the normal question I get, yes I do have a bit too much free time on my hands.

by ·Comments Off on Forecasts aren’t Commitments

forecastI wanted to examine how teams that regularly fail to deliver forecast work erode trust within an organisation. When a team has eighteen completed sprints without ever meeting a sprint goal then you know that there are hidden issues.

A development team in Scrum forecasts the work to be delivered in the next sprint based upon past velocity and team composition. Having unfinished work at the of a sprint is sometimes unavoidable, when this becomes frequent the team has a problem.

I think it was Mike Cohen who said ‘An estimate is your best guess of how ladamsong a task will take based upon your current knowledge’, occasionally sprints goals will not be met but this should be the exception. The late and great Douglas Adams said “I love deadlines. I like the whooshing sound they make as they fly by”. Fortunately in Scrum the deadlines are always fixed for sprints but the quantity of work delivered can vary due to many reasons including hidden complexities, unknown dependencies, sickness or misunderstandings.

Management within an organisation can view a team frequently ending a sprint with incomplete work as:

  • Lacking in the required competencies or skills
  • Unable to estimate and accurately plan its work
  • Inexperienced in Scrum and value delivery
  • Untrustworthy and unable to live up to its commitments

Software development has a poor image with many projects overrunning and massive cost increases. Agile is a tool that can be used to try to change this situation.

A team should strive to collectively achieve its sprint goal and deliver the sprint backlog. This will not always be possible as we continue to push performance and increase capability but if we are missing the sprint goal more often than not then there are some issues we can consider:

1. Datadata

The team needs to track its velocity – the amount of work completed each sprint, ideally in story points. The average velocity over the last three sprints, averaging the middle eight of the last ten sprints or a simple average of all sprints will be fine – just keep the metric consistent over time.

In addition the team needs to know at the start of a sprint planning session who will be available for the sprint and how much time that they are available for (100% in an ideal world).

Ensure transparency is maintained, if a story does not meet the definition of done at the end of a sprint then it is returned to the backlog and no points are claimed against the unfinished work. Generally do not split stories to be able to claim work, do not re-estimate remaining work and do not automatically roll work into the subsequent sprint.

Utilising a sprint burndown chart, updated at the daily scrum will also help the team maintain a realistic sense of progress.

2. Realism

The development team needs to decide how much work that they can accomplish within the sprint. It is not up to the product owner to push an unreasonable amount or for the scrum master to set a stretch goal but it is for the developers to agree as a team how much work that they realistically believe they can accomplish within the sprint. By all means use previous velocity, available skills and a chart of who is available but as a team they need to accept an amount of work to move to the done state during the next sprint.

So enough discussion, how do we fix this?

a. Retrospectivesretro

The team should focus in a retrospective on what the issues are and how to resolve them. The Scrum Master should facilitate the retrospective with the goal of the team creating actionable task
s to resolve the issue.

b. Do Less

Until we can do a task well slowly we cannot expect to be able to do it well fast. Permit the team the possibility of success by cutting the number of tasks for the sprint so that the sprint backlog size matches the team’s average velocity. When the team is able to complete the sprint goal in time it will begin a behavioral change within the team. Velocity will naturally increase for the team over successive sprints but this needs to be team driven based on the inspect-and-adapt cycle as supported by sprint reviews and retrospectives.

c. Refinement

As an experiment try spending more time on refinement and breaking down user stories. Ensure estimation is performed by the team as a whole, planning poker is ideal for this and ensure a reference set of stories exists to prevent estimate creep.

In summary, it is better for the team to predictably deliver less for the sense of achievement and the increase in stakeholder trust. Velocity will naturally increase over time but needs to be team led based on retrospective driven improvements.

If you have any thoughts on unfinished work at the end of sprint then please comment on this post or e-mail me as I would welcome any discussion.

by ·Comments Off on Islands not Silos

Islands Good, Silos Bad

A recent conversation with a colleague made me think more carefully about the metaphors we use when discussing change.

We talk of functional silos and siloed environments where groups, often departments, formulate their own compartmentalised strategies and work in parallel but separately from the rest of the organisation. These insular groups work with little or no interaction transferring work in a traditional waterfall manner. They draw identity, power and status from within their closed culture and are unlikely to share resources or collaborate with other groups due to a general distrust. Silos operate with top down micro-management and are poor at bottom-up communication and forming transversal teams.

The term ‘functional silo syndrome’ was coined in 1988 by Phil Ensor whilst working as an organisational development consultant. A silo is a structure, typically a tower, bunker or pit, for storing bulk materials such as grain, coal or cement. These structures hold their contents without permitting any movement or links between the silos, this is representative of disjointed teams.

The problem with the silo metaphor is that it is increasingly outmoded and invalid. I have yet to find an organisation that actually operates in silos, I suspect those that did have since failed or been forced to change.

We should instead talk about groups as islands with travel always being possible, if difficult, between them. Interaction between the islands can be limited, difficult, tiring and wasteful but it is possible, similar to having a test team in Scrum running in a successive sprint to the development team.

By building bridges between teams, colocating, creating a shared vision, forming cross-functional teams, promoting self-organisation and improving collaboration we reduce overheads and produce better and higher-performing teams. We do not have a choice in this, our customers require us to improve now or we will lose out to more dynamic competitors.

So next time you see heavily functional organisations with unaligned departmental groups think islands and not silos for a better systems model.

Island Bridge

by ·1 Comment

Sir Mix-A-LotWe are all changing to use big visible charts as an effective method for communication. These charts should be for things that we care about as a team and ideally are hand-drawn, wall-mounted and easy to understand.

The boards act as information radiators to anyone walking past and are a great way of building consensus and understanding within the team. Boards can be used for many different reasons and this post is an attempt to list some of them. All of these boards are temporary and should only be used whilst they serve a purpose.

Create boards anywhere, on walls, over glass, around pillars or freestanding. You can use mounted or movable whiteboards, foldable cardboard, whiteboard paint, magic whiteboard (static film). I have only listed physical ideas here and will cover electronic ones in a later post. Board types I have used are as follows:

Type: Task Board / Scrum BoardScrum Board

Function: The standard Kanban board show the current state of the Sprint and acts as a focus to the team during development.

Notes: As well as stories and tasks the board normally includes the sprint goal and end date, retrospective actions, sprint burn down, holidays and absences, Definition of Done and Definition of Ready. Avatars, work in progress limits and identification of blockers can also all be shown on the board.

Type: Program Board / Portfolio BoardProduct Board

Function: We can create boards at a higher program or portfolio level to give a bigger picture view to activities. This can include vision, full idea generation, approval process, engineering and delivery (if you have the space). By including the full life cycle, from concept to cash (Mary & Tom Poppendieck), we can work better together as a company to drive value

Notes: Look to Obeya (‘large room’ or ‘war room’ in Japanese) to give visibility to the entire development process.

Type: Feedback Wall (Niko-Niko Calendar/Happiness Index)Niko-Niko Calendar

Function: This is a method for tracking the mood of the team through a sprint as data to take into the retrospective.

Notes: Create a calendar with a square per team member for each day of the sprint (see picture). Ask each team member to draw a face on the chart to represent their mood as they leave each day. This data aids reflection within the sprint retrospective.

Type: Idea Board / Innovation boardIdeas Board

Function: Instead of waiting for the sprint retrospective; make an area for anyone to record new ideas at any time. An area for successfully implemented ideas can also reinforce positive behaviours.

Notes: By writing ideas during the sprint we can find a wider range of ideas. This technique can be used to ensure ideas generated during a sprint are not lost by its end.

Type: Modelling Board / Design BoardsModelling Board

Function: Agile modelling allows interested groups to gather around a whiteboard to create and evolve a model for the system being developed. This is a quick and visible method that allows wider involvement and input post-meeting by others who see the board.

Notes: Photographs of the model/design is often sufficient as a record when stored to a shared wiki.

Type: Release Board (alternatively Feature Board)Release Board

Function: A representation of the current state of the release split by sprints with burn-up charts. This can be elaborate with a full breakdown of the backlog into releases, sprints or a more agile breakdown of the current release only with focus only on the next three sprints.

Notes: This chart can be broken down for a release or by feature.Risk Board

Type: Risk Board

Function: A visualisation of the risks present upon a project.

Notes: As well as the identification of the risks, the mitigation activities can be tracked along with a graph of overall risk exposure and trends.

Type: Happiness DoorHappiness Door

Function: A Management 3.0 method for collecting engagement and satisfaction for meetings as people leave. This collects information in order to make the events more valuable to everyone that attends them.

Notes: Place three satisfaction indicator graphics onto the door (happy, neutral, sad – sunny, cloudy, rain or any other set of three) and ask everyone to write a post-it summarising their thoughts on the meeting and post it onto the appropriate place door as they leave.

Type: User Story Map (Story Mapping)StoryMap1

Function: A user story map is a grid containing a systems functionality allowing better release planning. Visualising structure enables a higher-level product view solving a potential issue with iterative development.

Notes: Functionality (user activities) is listed horizontally along the top of the grid from left (high priority) to right (low priority). Vertically tasks are added below the related user activities. Releases and sprints can then be determined by prioritising and ordering this work on the board.

Type: Affinity WallAffinity Diagram

Function: Used to organise and categorise information into logical groups.

Notes: Following brainstorming the team organises post-its into related themes and then titles each group. This method allows visual clarification of problems and identification of potential solutions.

 

I would love to hear about other visualisations that aid projects so if there is a board type that you use that I have not listed then please add a comment containing a description.