The Scrum Master

Recently, I have been enjoying reading "Professional Scrum Development with Microsoft Visual Studio 2012" by Richard Hundhausen.

One important thing that he reminded me of, about being a scrum master, was the servant leader attitude, eloquently encompassed by the words of Lao Tzu in the Tao Te Ching:

"When the master governs, the people are hardly aware that he exists.  Next best is a leader who is loved. Next is one who is feared. The worst is one who is despised.  If you don't trust people, you make them untrustworthy. The master doesn't talk, he acts. When his work is done, the people say "Amazing, we did it, all by ourselves!"

How Agile sets up teams to be Excellent

Agile is an excellent framework for organizing a team to produce work. But it says very little on how to make that team excellent at what they do. And that is one of Agile’s strengths – it allows a team to find its own way to excellence without imposing rules.

Actually, Agile says *almost* nothing – but it does say this:

-      The best architectures, requirements, and designs emerge from self-organizing teams

-      Agile processes promote sustainable development.

-      Business people and developers must work together daily throughout the project

-      At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

NB: taken from the Agile principles

These principles are still somewhat vague: we have to look at Agile Methodologies, like Scrum, to see how these can be done.  Scrum introduces the Scrum Master with guidelines to promote sustainability, daily working, and reflection in retrospectives.  But the Scrum Master is a servant-leader to the team, and from here Scrum is silent on how to ensure the team is behaving as an excellent team.  Or rather, Scrum, and Agile as a whole, leave the door open for excellence to take hold.

Excellence 

Here excellence is the art of doing things easily, even if they are difficult. It’s maximizing the amount of work NOT done, when you can reach your goals with the minimum of effort, stress, complication. This could have been taken straight from the book of Lean, Occam’s razor - climbers know this as "flow".

Many examples of excellent teams are all around us: A medical team performing open-heart surgery, fire-fighters, an IT support desk, Air-traffic controllers.  In sport: an F1 pit team, a yacht crew, and of course, a rugby scrum. Even in the animal kingdom you can find Wolves, whales, bees and ants whose teamwork is excellent.

Excellent teams are recognized as being excellent by the following characteristics

-      They have a positive outlook with drive and purpose

-      They Communicate well, are Friendly, and even have Fun!

-      They are Supportive, they Share and Learn together

-      They are inclusive, they Trust and Respect each other, are Open and Honest with each other

How then does a team gain these characteristics?

Firstly through awareness: Be aware of when you are excellent, as an individual and as a team. Notice how you get things done, when work is easy, when the team ‘Gels’, or when it delivers. Don’t focus on the negatives – this is practicing to fail. Better to enhance the positive and use the ripple effect to raise all round ability.

Next is buy-in.  Ask the team how they think an excellent team behaves, how work should be done, what it would be like to work in an excellent team. Ask them what actions they could take to encourage that behaviour. Since it comes from the team itself, they will be more receptive to start acting this way.

Ask them what the benefits of excellent teams are? to the team itself, their department, the organization, their customers. The potential alone can be a great motivation.

Finally, make time for the team to update the issues in retrospectives and other discussions, issues such as obstacles to excellence, how to give each other support, and how to build on current successes into areas still below par.

These concepts and tools can easily be combined with Agile methodologies while still preserving the responsibility and synchronicity of the team, and also helping them on the way to discover their own excellence.

This blog was inspired after attending the Technical Excellence course from Meta.  Many thanks to Jo and Di for their insight and support.

When to estimate in Story Points and when in Hours?

Yes, you do need to estimate twice, but at different times and for different reasons: 

Stories should be estimated in story points as soon as they are found. As soon as the PO adds them to the Product Backlog, they should be given to the team for estimating. This can be done in a an ad-hoc way e.g. after daily stand up, or at a regular story-pointing workshop. Doing this allows the PO (and everyone) visibility on the total size of backlog, and allows effective release planning. This also allows the team some visibility of future stories and give input to the PO on options, issues and possible designs. 

So that means in sprint planning, the PO and the team can know pretty accurately what stories will be in the sprint, based on their previous velocity. Planning is split into two parts. First the PO presents the next priority stories, the team discusses them and validates the story point estimates. They do this until they have enough to stories in the sprint. This is the Sprint Backlog. 

The Second half of the meeting is about taking the Sprint Backlog stories and breaking then down into tasks for the team to carry out. Each task should be small so as to be easily understood and carried out. They should also be estimated in (ideal) hours. This has several uses: 
1. Tasks shouldn't be larger than 12 hours (my measure). This keeps tasks small and simple and will highlight problems quickly 
2. It gets the team really thinking about how they will implement the task 
3. When the team starts the task, they know the time it should take and can raise an issue if they cant meet it. 

And of course the team can get another measure of workload against capacity using the total number of hours available to the team, versus the total number of hours for tasks. 

So both types of estimates are necessary for different reasons, but doing both in planning is too late for release planning, and makes the planning meeting very long.

Blog Disclaimer, Comments and E-Mail Policy

This is a personal blog. The views and opinions expressed here represent my own and not those of the people, institutions or organizations that I may or may not be related with unless stated explicitly.

Also, my thoughts and opinions change from time to time as I come to learn more and develop my understanding about the things and issues that I am blogging about. This blog just provides a snapshot of the knowledge, views, and opinions that I hold at a particular point of time and these might most probably change over a period of time. I reserve the right to evolve my knowledge, thoughts, and viewpoints over time and to change them without assigning any reason.

My blog includes links to other sites/blogs operated by third parties. These are provided as a means of convenient access to you to the information/opinion contained therein. I am in no way responsible for the content of any other sites or any products or services that may be offered through other sites.


Comments and E-Mail Policy:
Comments are welcome. However, note that, tasteless and insulting comments may be deleted. Any personal remarks and attacks may be deleted. The same holds true for off-topic comments. Any comments that reek of link spam or marketing messages WILL be deleted.
I am not responsible for the content in comments other than those made by me, or in blogs or other online content that I may link to.

E-mails are welcome and you may write to me at: donaldewart[AT]yahoo[DOT]com.

Please note that I may not be able to reply to all comments and email.

Vertical: the Agile Approach to feature break-downs in a cross-functional team

Its vertical, not horizontal

Very often, the way that requirements - usually described as stories or features - are broken into tasks is along a horizontal paradigm.  But in an agile context, this is the wrong way to promote flexibility, efficiency and teamwork- in short, agility.

by horizontal, I mean in the sense of layers of an application, an architecture that works in separating the presentation, business logic and data handling parts of applications.  But should you create a breakdown of a story into tasks along these layers?
For example, a story "as a customer, I want to register on the website to gain access to personalized services"  registration data might include name, address, phone numbers, email address, passwords, marketing preferences, etc. Breaking the story horizontally would get the following:

1. write page HTML
2. write JavaScript form validation
3. write business level logic
4. write database queries
5. Write test cases
6. execute tests

 The problem is, we have just broken this down in accordance with waterfall.  You cant start working on the validation, before the HTML, and you cant finish the business layer until the database work is complete.  But worse,   you must complete the first four tasks before doing any testing.  So by breaking this along layers we have introduced a mini waterfall.  If each story is treated in the same way, this will lead to terrible issues with dependencies, throughput and team "silos"
This is a situation that can often happen, because it "seems natural" to do it, and is what developers and testers can easily identify with.  However, this is a trap.

Instead, stories should be broken down vertically!

A vertical breakdown is where tasks include all necessary layers of the application to complete a tiny peice of functionality, including testing (and any other phase).These tiny pieces are worked on and delivered by several members of the team at once - i.e. when the designer is building the html, the developer can also code the business logic, and the tester can write test cases.  So a vertical breakdown might look like this:

1. register name
2. lookup address
3. validate email address and password
4. save marketing data

here are the advantages:

• The team can really start working together, rather than just working on bits of the same thing - no more silos
• The team can now start on the first tasks together - designer, coder, tester. 
• These tasks are small, short-lived so they can soon be into the test phase, shortening the build-test cycle.
• if delays in the sprint happen (i.e. due to underestimation, sickness, priorities) work can stop on the story after any of these tasks and the work done until now is still deliverable.

 It can be a difficult change to a team's way-of-working, as they may have to go against years of training and thinkng in this way, but not doing so will doom the team to stay at a low level of agility and efficiency. But it ca also be a sig of a team;s maturity that they can start working together on the verticals.

Can the wrong tools stop you being agile?

One of the Agile manifesto's preferences is for people and collaboration over tools and processes.  For example, having a 2 minute face-to-face conversation is preferred over sending an email.  This is an admirable foundation for the philosophy, but what happens if the environment, technology or tools you must use on a project get in the way of collaborating and being agile?

My current project is customizing a Siebel installation as the organization's CRM solution, and so we have to deal with Siebel's technology.  I have to admit i have never worked with this technology stack before, and so I am relying on the solution architect, team leaders etc for their views on this, which I respect.

The issue comes when it is time to deliver new code to the test environment. Development and unit testing happens in a separate dev environment, then released to the SIT testing environment for system testing. This is the first step in the delivery chain, so each release to SIT becomes part of a collated release to UAT, etc.

Releases can take the form of an SRF, a Repository update, Static data, Workflows, etc.  The problem is that these releases are time consuming and have to be made under a release management process, which involves two other teams (release management, environments) and creating interim documentation (release notes). Because of this, releases cannot be ad-hoc or flexible, and have to be scheduled. This was exacerbated by the release and environment teams being unwilling to perform more than 2 releases per week.

Unfortunately, the team has morphed this into the need for a release plan - scheduling to finish user stories for a certain release date - and so a lot of planning day is consumed by trying to fit user stories into the release schedule so that a tester has enough time to test it.  And what does that look like - mini waterfalls in a sprint!

This has some obvious (to me) drawbacks, in that a missed release date could delay a user story by two days! even for a 2 minute bug fix, so quick turns around times to improve through feedback were non-existent.

In terms of Scrum, it meant that the team were always focused on delivering to the release plan, rather than having the flexibility to deliver when ready (they were even admonished for delivering a story early, as it was not in the release plan!).  Also, since no work could be delivered after the last release, there was a premature end to the sprint which increased the likely hood of stories 'carrying over' to the next sprint, against agile principles. It was estimated that around 10% of capacity was wasted because of waiting time or lost time.

Finally, I also had the impression that some of the team, including the release manager, were deliberately using this as an excuse not to be agile as they didn't want to change.

Unfortunately, in dealing with this situation, I had to wait until the release manager was replaced to get any movement in this area.  When that happened, I immediately went to daily releases - which although not the ideal, helped a lot. 

It meant that I could downplay the importance of the release schedule, and so get back to a more flexible approach to taking on and delivering work, and it meant that we could have releases up to the end of the sprint, so using all available capacity.  I would have preferred to have dropped the idea of a release schedule completely, but this bit of team culture was ingrained pretty deep and the teams elected to keep it.  Our new release manager also helped a lot, as her whole approach was one of helping to deliver, and being flexible but controlled.

The ideal situation of continuous integration is not always possible: The limitations of older technologies, together with old-style ways of working, can severely impede a team from realizing its full agile potential.  But by approximating to CI, and having the will to be flexible, can improve the situation - we were able to reclaim the 10% capacity, and greatly improve the pressure on testing.

Team Culture: difficult to change

I find that one of the most difficult aspects of change a team may have to undergo is one of culture.

Changing the membership, meeting times, workload, locations etc of a team, its relatively easy to get buy-in, as long as you give good reasons and gain consensus.  But there are other aspects of moving a team to an agile way of working that call for much deeper and controversial solutions.

Many teams (including my current ones) on their first agile project still have old-style tendencies that hinder best performance and becoming fully agile.  For example, even within the same team, there can be an "Us and Them" attitude between developers and testers, and at times with POs also.  While these are obvious divisions, this is in the context of traditional management methods which set up these divisions for their own convenience.  But this can be a continuous source or argument, shirking of responsibility and, frankly, arse-covering which all detract from productivity.

To be fair to my teams, the culture of the project did not start with Agile - in the beginning it was a traditional, quasi-waterfall project with design, 3x development and test teams, all with team leaders and managers in the usual hierarchy.  This has been a difficult culture to change: we still need the people who are the team leaders, even if their role has diminished significantly, but this preserves the divisions between them.

One of the central tenets of Agile is its focus on teams, teamwork, and working together towards a goal, and so members need the space to be flexible and adventurous in working outside their comfort zone role when needed.


One example here is when a team realized they didn't have enough test resource to test all the stories developed by the developers.  When given this problem, the team mulled over the suggestion of developers testing each others code, with a caveat that a tester would still do final testing.  Most of the developers were ready to do this, but when pushed, the testers - and test manager -  somehow managed to find enough time to do the testing after all (by working weekends!).

Another example is within the test team themselves - when none of the Siebel tester's in a team would test a Data migration story because "they don't do that"

A true cross-functional team would allow this to happen - in a controlled and visible way so as to maintain quality - but also to enhance productivity without using more hours.  But I felt that while the old divisions remain, Agile's goal of super-productivity can only be approximated.

To help solve these problems, or to try to break the divisions can call for difficult decisions, such as the obvious one of removing the team leaders - but this is often not possible or popular!  Better to engender a new culture of sharing, team-ownership and safety to allow team members to be adventurous.  This could be done through workshops where testers show developers how they test, and vice-versa, and inviting testers to develop some stories in line with their ability (Testers are often good developers too).  Not only does this encourage all the good things of agile teams, but supplies a form of training and teamwork not possible in traditional methods.   

The Team in The Programme

Sept 2010:

As I join The Programme, there was still 18 months left to go - 15 for development and 3 for the last rollout.  The team structure is as follows:

• 3 teams of cross skilled developers, testers, and BAs - team sizes about 10 in each
• Most developers are from the same consultancy, they are a mix of Siebel, OBI and Data migration developers - each discipline has a team leader. There are around 14 devs in London, 3 in Mumbai
• All testers are independent contractors, lead by a test team lead (who doesn't test)
• BAs are mostly contractors, some permanent employees too.

There are around 10 BAs, lead by a team leader.  So three BAs in each team acting as proxy product owners. Interstingly, the "BA team" is using Scrum to organize their work, so they have a separate stand-up each day to synchronize on the analysis of the problem domain.  While this is outside of my scope, I will find out more about this - Scrum applied to analysis.

Other people on the programme: Solution Architect, Programme Manager, Director, Infrastructure team, Support team.

Parameters of content

In starting to write this blog., I first asked permission from my department managers, line managers and programme managers for the kind of content that I should conform to.  Mostly they were very open to the idea, and were happy for me to do this - but in an anonymized way - so names are changed to protect the innocent.

I dont think this matters, and will have little impact on content, as I intend only to document, explain and review the decisions of the programme in terms of Agile Methodology

Start of a new blog

This is the first entry in this blog, so i should eplain what I am doing here.  This space is for me to note, remember and share the experiences, activities and lessons learned that I encounter in my role as a Scrum Master and Agile Evangelist.

I will try to bring this up to date with my experiences so far from the past 3 years, but also add to this with my current role.

While this is predominanlty for my own benefit, please feel free to review and add your own comments and suggestions, and I will try to answer any questions too.