Andrew on Agile

During my ScrumMaster certification, Mike Cohn recommended that the size of a cross functional scrum team should be between 5 and 9.  In a recent exercise, we tried splitting a scrum team three ways – 5-6 people in each team - for the next release.

At the end of last year I counted 16 people in a scrum.  For most of the release the team size averaged 12, consisting of a mix of product managers, QA, front-end engineers, software engineers and the ScrumMaster.  16?  It never meant to get that big, but with an addition here and an addition there, it did.  It was too big.

The scrums were starting to take too long, there were too many stories in the sprint for one team to truly keep track and impediments were flying around everywhere.  Risk was starting to creep into each sprint and eventually the release.

I put it to the team that they should split in half for the next release and while some members were ok, others really objected to the idea.  They felt it would generate unnecessary tension between a team that had grown strong together.

Due to the type of work within the first sprint in that next release the team worked as one again, but agreed tentatively to an unequal split (1/3 to 2/3) for the following two (and final) sprints.  It was ok, both teams had a couple of issues mainly down to the fact that they were building three applications which all needed to communicate with one another, but the smaller team certainly preferred being small.

So now they’ve split into 3.

It’s brilliant.  The teams are made up of 1-2 QA, 2-3 Engineers and a Product Manager.  The teams were encouraged to go through the agile scrum motions how they saw fit.  The smaller size enabled intense collaboration during a short planning phase, resulting comprehensive stories.  Poker and sprint planning was a breeze, less big personalities to get in the way of proceedings, and it was so much easier to keep on top of the progress during the sprint.  The software’s of high quality.  It’s done.  It contains a good level of tests and the quality of the code is great.

Now that risk is greatly reduced.  In the sprints before if something started to go wrong it could have affected the whole team.  All members would get distracted by the issue and if it didn’t get resolved and the goal compromised, the team would be left demoralised by all the drama such failed sprints bring.  Oh yeah, and the team members love it.

So if it was going good, then the team gets bigger and you start to have problems, or if you’re trying things for the first time and some members aren’t engaging, break it down.

I’ve been having a series of conversations lately with one of my engineers about learning on the job.   By this I mean that technological problems get figured out during a sprint.  These problems usually arise from implementing technologies that aren’t so well known by the engineering team.  A recent example for us would be finding solutions for complex queries with Fluent NHibernate.  The conversations were sparked by recent events during our last release where a sprint goal was compromised by the introduction of a new Domain Driven Design (DDD) architecture, and the previously mentioned object relational mapper (ORM), Fluent NHibernate.

The engineer’s argument for learning on the job centres on the satisfaction gained by solving technical challenges presented by new technological ideas.  As a manager, engineer’s job satisfaction is very important to me.  In an unsettled economic climate such as the one we’ve just been (and perhaps still are going) through, it becomes even more important to use everything available to keep morale high.  Our favourable stance to adopting new technologies over the past couple of years – we built a production app in .Net MVC right through its preview stages, releasing the app as MVC was released – has kept the engineers interested in their jobs.   That being said, introducing a new technology is accompanied by risk, risk that can turn into a high cost.  Learning on the job during the sprint is risky because it can create impediments that are very difficult to remove.

In order to find the right balance it is important that all the engineers know what they’re doing throughout the sprint.  If a sticking point arises, e.g. a situation where you notice an engineer stuck with their head down for hours on end, a couple of scrums pass where they say they’ve got 1 or 2 hours left and they’ll be finished that day but they never do, then you know you have a problem.  Sometimes this can be solved by pairing, but probably it’s a sign the team hasn’t done enough homework.

We just halted the introduction of a messaging technology into the next release and are mid way through a two week planning phase.  The aim is to take a small sideways step in order to make sure the engineers are technically up to speed with what’s going into it. 

The focus of the first planning week has been on story generation, next week we’ll be exploring those stories further to find potential engineering sticking points. When they are found the whole engineering team will come together to investigate the solution.  This object of this exercise is not to create solutions for all our potential problems up front, as any changes to the backlog during the release could render this a waste of time, but to use the potential problems as case studies to ensure the engineers have enough knowledge about the technologies we have introduced before embarking on the sprints.

This is not something we will do between every release.  A series of weekly, hour long sessions to contextually spike the implementation of the messaging technology using a current production app will get underway as soon as the release starts.  We will only introduce it across our range of production apps when the team feels ready.

This is what I consider learning on the job.  There will inevitably be some learning during the sprint, but the aim should be to control that as much as possible.

As part of the transition to agile scrum at one company I worked for some key software engineering considerations: code maintainability, test coverage, extensibility and scalability came under review.  Although products were being delivered, problems were being built into them.

As an engineering team we set ourselves the challenge to start practising TDD (Test Driven Development) within a year.  This goal would force better code quality and the code would be future proof as it would be designed to accommodate change.

Such a goal isn’t easy to reach.  If the engineers aren’t used to building software in a certain way they can’t just start doing TDD.  There needs a period of education; engineers need to loose bad habits.

Sending the engineers on a course could be an option, however, aside from the fact there may be no budget for that, to truly progress the adoption of a sustained learning process is far more beneficial.

We set up a series of weekly hour long internal seminars.  Both engineers and the business made concessions; the time of the seminar was 1.30 – 2.30, half over lunch time and half during business hours.  We booked a room away from the bustle of daily working life, organised a projector and all the engineers week by week presented on topics we believed would improve their standards of coding.  We started by examining design patterns, but soon found we needed to revisit the core principles of OOP (Object Orientated Programming), with particular focus on the Bob Martin’s PinciplesOfOod, also known as the S.O.L.I.D. principles.

Armed with a couple of really good books – Bob Martin’s book Agile Principles, Patterns, and Practices in C# is a fantastic teaching aid – and a lot of support for each other, over a period of six months we moved on to look at the TTD approach and the team’s standards started to improve.  After those six months, all new work had to be built using TDD.  This was partly successful during the following six months because it was not so easy to write tests against legacy code bases.

A year after the comments from the contractor, the team worked on a green field project.  After only four weeks the system was complete.  Code maintainability, measured using Microsoft Visual Studio’s code metrics tool, averaged 80 points (which is good!).  Test coverage was around 50% for the entire solution, but more importantly 80 -100% in the solution projects containing the business logic (a good post for how to write good unit tests).  The engineers were practicing TDD 70% of the time, hindered by falling behind schedule due to problems communicating architectural design expectations.

This is a great achievement.  Now the team pair programmes most of the time, working with each other to strive for excellence.  Subsequent topics for the seminars included looking at “interfacing the ball of mud” in order to create testable code against legacy systems not designed for testability.  The team designed strategies for refactoring legacy systems into a testable architecture and began adopting DDD.  The internal seminar is a permanent fixture, anything can be discussed, although it is best to select topics relevent to the business.

It took the best part of a year to see real improvements; I don’t know whether you think that is too long?  I don’t.  It’s difficult for a team to massively shift their practices whilst minimising the effect on their output for the business.  The point is, if your business and team are willing to commit the time – the hour a week for the seminar – and your senior team design and constantly review a quarterly syllabus, the team will teach themselves and improve the quality of their work.

I wanted to post this as an update to the original post on how to estimate story points using the poker planning technique and involving your QA team.

In the first post I describe how a poker planning session almost broke down when including the Quality Assurers in estimating the relative size of each of our stories.  Just to get through  that session we ended up producing one or two estimates that didn’t include the testing time.

It’s amazing how adaptable people can be.  On our second attempt, only 2 weeks later, I’m very pleased to say our session went brilliantly.  They key to this success, I feel was down to the ScrumMaster.  They took the initiative, pre-empting another possible disastrous session and clarified some of our own rules.

Last time, because both engineering and QA were unused to thinking about delivering stories to done including each other’s time, we ended up settling on the highest value either the engineers, or QA, or a hybrid could agree on.  There was very little unanimity, nor was anyone really convinced we were providing estimates to the best of our ability. 

This time we started our session by reviewing a very simple process designed for our team that the ScrumMaster had put together.  If consensus could not be reached by the first attempt at laying cards, try again.  If still no consensus after a round of discussion, try again.  On the third attempt if there was still no consensus we would settle on the highest value, as we had in the previous session.  Mike Cohn suggests in his “Agile Estimating and Planning” book to “…continue the process as long as estimates are moving closer together…”, but in the past this hasn’t worked for us hence the 3 time cap.

From there on in, the team set about story pointing.  We had about 9 stories to estimate and in about an hour and a half we were done.  Estimating for each other’s disciplines still didn’t come easy for everyone, but when someone struggled, the team worked with them so they could understand what they were thinking about.  Only once did we not reach a consensus by the third attempt, and that story had such a high estimation it would need to be broken down further.  The mood of the session was very positive leaving all present extremely satisfied with the result.

So, the first stage particular exercise to incorporate QA into our story point estimation sessions has been a success.  Yet another leap forward in our journey.

There will be more to follow on sprint planning with QA and integrating the seating plan of teams who are already co-located.

Good stuff.

We had just finished the first stage of a green field application and missed our sprint goals.  Damn!  When we first saw a problem, should we have pulled some work out of the sprint?

 This is not something anyone should be afraid of doing.

Let’s look at what happened.

The competent team had worked together for 18 months on various projects.  A new style of architecture was to be introduced to improve testability and in preparation for this shift we had invested in several internal group educational sessions, as well as some good debates during sprints.  At the start of the sprint we didn’t commit to as much work as we had capacity to do, however we were pretty close.

After 4 days we hadn’t delivered anything to test.  Complications with the precise approach to the new architecture were holding up the project.  At the end of the 5^th day we still had nothing into QA, so we held a 2^nd daily scrum.  We agreed if we finished engineering a couple of  stories so testing could start by the end of the next day, the engineers would finish the rest of their work during the week and time could be made up by engineers pair testing with QA.  A little ‘waterfalacy’ but it was only 1 sprint so never mind!

Can you guess what happened?  We didn’t meet the sprint goals and were left with about 40 hours worth of work.

I’ve been in several sprints like this where for various reasons the goals haven’t been met.  The end of the sprint is unbearable.  The team gets micro managed; frustration grows and turns into panic – a desperate rush to get things done during the last couple of days – then there’s the realisation at the 11th hour of failure. 

Failure!

I don’t like that word, nor does the team who’ve worked so hard to try to reach their goals.  The effect it has on morale is a real pain to manage and it doesn’t encourage better quality work.  To avoid ‘failure’, teams cut corners and in my experience the tests – so important in modern-day software engineering – go first.

So what should we have done? 

The real focus should have been right at the beginning in sprint planning.  The potential unknowns associated with incorporating a new technical design into a green field project should have been taken into consideration by the team when confirming their commitment.  It’s easy to say in hindsight, but the team should have committed to less in the first place.

That said, if the team are confident that their commitment is achievable, as they were in this instance, and you find yourself in the same place as us, you have three options.  The first is to carry on building, accepting the risk of digging yourself a deeper hole.  The second: abort the sprint.  The third is to pull some stories from the sprint with the approval of the stakeholders.

We know the first option is a BIG risk as you may well end up compromising the quality of your product.  The second, I don’t think the situation was serious enough for an abnormal termination.  I prefer the third option of redressing the expectations and pulling something out of the sprint.  I just think it’s more practical.  There is no need for all the drama the other two options create and the sooner the stakeholders are informed of any problems the better.

I don’t think this solution is right for every situation.  What’s the point of having a goal if you can just move the goal posts when you feel like it?  But sometimes, such as the example Mike Cohn alluded to during my ScrumMaster certification where you have a team new to scrum who are finding their velocity, or this situation where there was a good reason for changing the architecture, then I think it’s the best solution as long as everyone agrees.

Previously in our sprints we included QA time by adding a buffer to the engineer’s task estimates.   From now on, to provide greater visibility of the challenges QA might face whilst testing each story, we have started to include them in both the story point estimating and tasking sessions.

We started out by suggesting that the team (QA and Engineering) collectively estimate a story point value not only for how long it takes to engineer, but also how long it may take to test (relative to another of course). 

This didn’t go as expected. 

Some members got it and were able to take into account the advice or suggestions from their peers and re-evaluate accordingly.  Others found it very difficult to accept how QA and engineering could effectively estimate each other’s time.  

Such reservations were confirmed during the estimation of the second story.  The engineers agreed a 5, QA initially put down a 1.  The engineers then suggested to QA what might be involved in the story, but QA re-evaluated only a 2.  This resulted in a lively debate about what we were doing, how “pointless” this all was, etc, etc and the session pretty much broke down.

The strongest opinion of what to do next was for the engineers to story point their value, QA to story point their value and then add the two together.  For the sake of moving on we tried it.  We went back to the first story, engineers a 2, QA a 1 so we got 3.  Fine.  Next, engineers 5, QA 3 and we have 8.  This is easy!  Story 3: engineers re-evaluate a bit between 13 and 20 but settled on 20, QA 5.  Ok, so we suggest either re-evaluating again collectively to see if we accept 20, or we round up to 40.  Nope.  Some of the engineers wanted to stick with the story point value of 25 and the previous debate flared up again.

Both engineers and QA understand why we story point; that we use the Fibonacci sequence to balance out the estimations.   They’d heard the bucket of water metaphor Mike Cohn used during my ScrumMaster certification ”… you have 25 litres of water, that’s not going to fit in a 20 litre bucket, you should use a 40″.  They want (and agree with the need) to be more integrated, but just struggled with the concept of collectively settling on a figure.  There was alot of confusion over the level of accuracy required.

After a lo————ng debate, to get through the session a consensus was reached.  In order to obtain our team velocity we just needed to be consistent over time.  The team settled on this: QA story point their value, engineer’s their value and to accept the highest.  From that point the session finished quite quickly; everyone was a bit frazzled but content with the result.

What we have done is wrong.  Settling on the highest value is fine if QA vote 1 and engineers vote 13.  But what if engineers vote 13 and QA vote 8?  Or QA vote 20 and engineers vote 13?  The real estimates for those last two examples would surely be nearer 20 and 40?  We are not providing an accurate estimate to the best of our knowledge at the time.  This is important for management to plan a release.  It’s difficult to accurately estimate for a long release period, but we should not knowingly underestimate.  This will need to be addressed again during the next session.

The goal is that the team will naturally start considering each other during estimating sessions.  They will get there.  Even the senior engineer who raised the most questions about the process at one point put down a 40 and justified it by saying “well there’s a lot to test”. 

We have just started with test automation which will help to bring QA and engineering together further.  We might also get there more quickly with smaller teams; yesterday’s was 3 QA and 7 engineers.

The positives from the story pointing session?  We can now clearly see the different challenges that QA face from story to story, which sometimes do not have a direct correlation with engineering time for the story.  This is definitely going to help us with both planning and execution.

Last month, for two days I was in the company of Mike Cohn.  It was in aid of my ScrumMaster certification, which was obviously something I paid for.  It cost £400 more than most other ScrumMaster certifications so the question is, was it worth it: the certification and the extra money?

As I’ve mentioned before, the company I work for as Engineering Manager has been practising Agile Scrum for nearly two years.  I’ve undertaken the role of ScrumMaster for some big version releases, as well as iterations for an ops rota.  I’ve also been in teams with other colleagues assuming the role.  I’m committed to the Agile approach to building software.  In my eyes it feels both logical and totally natural.  I like to understand how and why decisions are made; I think its right the people building a product are empowered to take control of it.  Becomming certified would officially cement the knowledge gained through a lot of hard work and problems exposed during our transitionary period.

So what about Mike Cohn?  One of THE figures in Agile, he was the first name I came across at the beginning of our Agile journey as I read Agile Estimating and Planning.  His latest offering Succeeding with Agile: Software Development using Scrum is obviously targeted specifically at Scrum.  A couple of people I had spoken to who’d been on the cheaper certification courses felt they were just “OK”.  I didn’t want my certification to feel just “OK”, I wanted to feel like it was an event.  I wanted to feel “certified”, to feel worthy of the new title I was gaining.  I’d only managed to see a couple of short Mike Cohn interviews before taking the decision to spend the extra on his course so I didn’t really know what he was going to be like.   Mike Cohn has a big presence - I could hear him way before I saw him – but my expectations were high and I really hoped he would deliver.

At conferences, sessions or courses such as these, if I get excited by just one new piece of information, one little nugget, something I can include in my working life that I know will make a difference, I generally feel it was worth attending.  This I got from the first slide!  The slide recounted the Agile Manifesto formulated by the 17 prominent figures involved in “light weight software development”.

In our office we know this manifesto, but somehow the word “over” has always been interpreted to mean “instead of”.  It seems this is a common mis-interpretation as this slide immediately triggered some debate.  Maybe, like me, you’ve heard “We don’t need to write documentation, we’re Agile”.  This is an excuse for being lazy: “If you are building a car you would expect engineering diagrams right?”.  To dispel the debate, Mike suggested preceding the word “over” with “preferred”.

OK, so not a massive revelation, but more nuggets were to come.  We discussed, sometimes at length, a range of topics.  These included don’t measure progress by the amount of documentation produced, the ZD Milestone (zero defect), the word “potentially” used in the phrase “potentially shippable”.  Potentially should not be interpreted as producing something that doesn’t work properly “it works, potentially, but it hasn’t been fully tested”, rather what’s built works without breaking and could be used in you software product when shipped.

We talked about sprints.  Zero sprints, analysis sprints, testing sprints, release sprints, stabilization sprints, technical sprints and how to build architecture over time.  We talked about the product backlog, the scope of “done”, how to avoid mini waterfalls and what can lead to an abnormal termination.  

I was able to discuss bits and pieces specific to my experiences, like what size should a scrum team be?  Our teams sometimes creep up to 16 and there have been days when I find myself thinking surely it’s too big.  I’d Googled it of course, and Mike’s slide confirmed 5-9 was a good size for a cross functional team, but what he also mentioned was Amazon prefer 2 pizza teams, teams you can feed with 2 pizzas.  Someone else in the group offered they measure team size by how many cups of tea you can make with one kettle.

Mike’s 15 years of Agile experience, combined with his affable manor, encouraged participation which nearly always triggered a healthy group debate.  This he followed and controlled – almost always with a knowing smile (no easy feat with 40 people in the room) - and when it had run its course he either strengthed it by sharing his experiences, or provided non patronising clarifications to common misconceptions.  Whilst expaining why aspects of scrum exist and where they came from, he articulated what he was saying in such a way you really listened. 

Throughout the course I felt like I already knew what Mike was talking about.  Obviously some of that was because I’ve been doing Scrum for a while, but as Mike explained it really is all common sense. 

This is the sort of “stuff” that I came on this certification for; to really look at scrum from the perspective of the different roles and from outside of my normal environment.  Discussing the transition, the release, the sprint, the different journeys people had been on, made me realise how far along that journey we have come.  I have a greater confidence in both my role and in how well our teams are doing Scrum.  I’m not assuming we’re perfect, but with emphasis on specific key words – “can WE commit to this” as opposed to a ScrumMaster asking the team “can YOU commit to this” – we’ll be able to fine tune our process.

At the start of our transition it seemed Agile was making it difficult for itself.  In a Google video we watched from 2006, Ken Schwaber told us there is no Scrum methodology handbook for your exact situation [11.47] (this may not be so true now there are so many books on the subject).  In the early days, because of this statement some team members never really took it seriously and it slowed our transition.   I can’t remember how many times whenever something got difficult I heard people say “… with Agile it seems no-one knows how to do it and they’re just making it up as they go along”.

I think our mistake was not certifying a few team members earlier, with Mike, or any other key Agile figures.  We certainly would have avoided some pain, especially in estimating (you’ll find story pointing much easier if if the team votes how long it would take to complete relative to another, don’t try to do it by complexity or difficulty).

So, back to the original question, was it worth it?  The confidence gains mentioned earlier easily justifies the certification, but the extra money?  To be able to tap into big, heavy, weighty experience such as Mike’s for two days, regardless of your industry, is obviously going to be worth it.  His expert delivery made sitting through those two days easy.  For the reasons outlined throughout this review, I feel this specific course was worth every extra penny.  To anyone involved in Scrum, if you’re thinking about it, I recommend booking yourself on it, even if your business has limited resources.  What it could save you is immeasurable.

I recently attended an evening presentation by Wille Faler at Skillsmatter, as part of the Limited WIP Society.  Wille’s presentation was a case study which described the lessons learned from a Scrum team moving to a Kanban way of working.

Wille started by explaining that whilst at the FT he had been part of a team consisting of 3 engineers, a QA and a Scrummaster / PM, that their taskboard was extremely busy all the time and although they had 2 hours for their sprint planning meetings, it took so long to identify what had to be done for the first few tasks, completing the rest in the time alloted led to reduction in the quality of  the story tasks at the end of session.

Switching to Kanban

The team decided then to switch to a kanban methodology.  He reported that the planning sessions became much more productive as they were able to adopt a just in time planning concept and minimum marketable features.  People stopped focussing on moving tasks around the board just to look like the project was moving, bottlenecks in testing were alleviated by engineers helping the tester to get the item to a done state and started automating tests using Selenium.

Although the team is no longer sprinting the still have by-weekly demos & retrospectives.

In conclusion Wille felt overall the team were more motivated, code quality was better because of fewer distractions, leading to less reoccurring defects and, although it was difficult to see how he measured this, the team’s output had increased 3 x (6 months work in 2 months).

See the full presentation here.