Agile:MK



Bringing together people living or working in the Milton Keynes area, who are interested in sharing, learning and encouraging the use of agile methodologies, such as Scrum, XP and Lean Thinking.

November Meeting Summary

Thanks again to everyone who attended the first Agile:MK meeting last month. All the feedback received has been positive, and the intent of this bulletin is to ensure the wider group gain some insight into the discussions that took place.

Item 1: Why are we here?
We kicked off the session with a small exercise to identify what we believed a valuable user group would look like i.e. what is worth dragging yourself along to on a cold winter’s evening! The group wants to network locally, share experiences and learning, encourage the adoption of agile in Milton Keynes, and drink free beer…

 Item 2: Discussion Backlog

During the initial exercise a large number of discussion topics were identified, these were prioritised to provide an on-going agenda for the user group. From this we were able to identify January’s session as “State of the Art”:

Item 3: Scrum in a Non-Software Environment

The main part of the session comprised a workshop discussion about using Scrum in a non-software environment. One of our group has just completed their first sprint (4 week iteration) and we started by understanding a little about the business.

Mindmap of Non-Software Environment

A general discussion brought out the fact that the business’ primary functions are stakeholder management, event management, workshop facilitation, fund-raising, marketing and communications on behalf of non-for-profit organisations across the UK.

Review v Retrospective

The discussion turned to the topic of end of sprint activities and we talked about both the Sprint Review and Sprint Retrospective. This is sometimes a misunderstood or confused part of Scrum. At the end of an iteration or sprint, the team goes through two specific processes:

1.      The team presents its outputs for the time period i.e. in this example, the team should present its strategy for the client. This should be presented to the business owner or customer of the product. The purpose is to ensure that throughout the project as more and more sprints are completed, the business understands what is being built and can feedback on both its quality and alignment to business needs. The intent is to ensure that the end result of the project is closely aligned to business needs.

2.      The team retrospects… The team asks itself ‘what did we do well in the last 4 weeks?” “what went poorly or needs improvement?” and finally “what are we going to do differently in the next sprint?”

These two activities are fundamental to the successful adoption of Scrum and represent the key objectives of firstly ensuring a deliverable meets the customer’s needs, and secondly ensuring a team continuously improves its capabilities.

Definition of Done and Acceptance Criteria

One clear area to consider when adopting Scrum in non-software environments is quality. Operational environments generally produce lots of different deliverables as part of meeting its customer needs. Rather than increments of software, this project is delivering documentation, marketing artefacts, events, workshops and is raising capital. How will the team ensure that each of their deliverables is of the required quality?
The discussion group started to articulate the concept of ‘Definition of Done’. For any delivered feature or artefact, the team needs to ask itself “How well has the feature been completed?” “To what level of quality?”
The essential part of a Definition of Done is that it is created by the team. Typically, the Definition of Done consists of a list of standards and agreements that the team agrees to adhere to for each of its deliverables. Team members should be transparent about these criteria and effective teams are able to challenge each other when these criteria are broken.
So for the project at hand, the question for the team is “what does a high quality strategy consist of?
In contrast, acceptance criteria is a term used to articulate the needs of the customer i.e. what should the deliverable do, what pieces of the deliverable does the customer assign value to and will therefore, pay for? The group outlined that acceptance criteria are the ‘things the customer wants’. So for this project the deliverable of a Strategy would probably include acceptance criteria such as governance strategy, fund-raising strategy and communications strategy as part of the overall delivery. Other criteria could include being written in English, available for download, in pdf and PowerPoint formats.

Scrum Board

The final part of the session turned to a more practical way of helping the team achieve its goals within a sprint – the Scrum Board. The group discussed the implementation of scrum boards, how they differ from Kanban boards, and some of the lean principles behind boards such as maintaining low levels of work-in-progress (WIP).

The Scrum board is typically a white board displaying all the teams’ deliverables and associated tasks. This makes the team’s activities transparent to everyone in the room and this transparency can have a significant impact on the team and management.

There are many forms of scrum board, and two typical implementations highlighted were [To Do – In Progress – Done] and [To Do – Analysis – Development – Test – Done]. We further discussed the relative maturity of teams adopting different styles, as well as queue identification and bottlenecks, and observed that more mature teams typically need fewer steps across the board.

The next Agile:MK meeting will take place on Tuesday 15^th January 2013 from 6pm – 8pm.
 The discussion topic will be “The State of the Art”

Registration: To register your interest, please join the LinkedIn Group at http://www.linkedin.com/groups?home=&gid=4686141&trk=anet_ug_hm