Tag: Agile

Scrum Is Not Enough!

~ Adam ~ Leave a comment

Let me start by saying I’m a big advocate of scrum (despite some of my posts in which I challenge it over and over again). Having said that it has it’s weaknesses (like any process), one I’m going to highlight in this post is the insular nature of some scrum teams.

The best way to explain this is to describe my own experience. When I started in the Scrum Master role I was very keen on continuous delivery and wanted the development team to produce a build every two weeks which could be supplied to the business to decide whether to deploy it or not.

We had a lot of projects on at the time and we were working very hard to meet the commitments my predecessor had signed us up to and get features out the door on time.

This went on for a month or two, we hit every deadline in the calendar and provided the builds to the deployment teams on the dates we’d agreed. So what happened? Nothing…

What I’d failed to realise was that despite our hard work over the last few months we’d failed to release a single new feature to a customer. The deployment teams had struggled to install our software into UAT and without any contingency (except when it was carefully planned for) we had no capacity to assist them or pick up any issues – until the next planning session of course (where usually the next feature was the most urgent due to “customer commitments”).

Development kept on working, features continued to be produced and deadlines were hit. But the customers were sat waiting, UATs couldn’t be completed (or in some cases even installed), and the business because frustrated with us because we weren’t available to help them get the product out the door.

So what went wrong?

This is where you may have to forgive my sleight of hand in the title. I don’t believe the problem was with the scrum methodology as such, merely the most common implementations of it. The first oversight was the handover, the second was the goals of the team. Let me explain…

Firstly the handover, the issue wasn’t that it was sloppy or that it we didn’t have consistent priorities across the business (although that certainly didn’t help). The issue was that we had one… A scrum team should contain all the skills and knowledge required to get a feature from concept to customer. Rather than handing builds over to the business to deploy we should have had someone from the deployment team working in the scrum team who would actually do the implementation. The team itself would then support the new feature through it’s UAT phases and out into the customer’s live environment.

The second failing I mentioned was the team goals. I have already alluded to this but the goal of the team was to “write this feature” whereas it should have been “deliver this feature to the customer”. Only once that goal has been met should they move onto the next one.

This continuity and accountability is a very powerful thing. Projects fail when departments don’t communicate with each other or their priorities are not aligned. Systems slow when there’s too much Work in Process (for example incomplete UATs) clogging up the pipeline and generating unplanned work. If you want to break out of this cycle you need to stop thinking about departments and handovers. Stop thinking of scrum teams as groups of developers delivering feature after feature and start thinking of projects being created and delivered by teams of people from all the disciplines you need.

If you can do that, then you can make your scrum team work for the business and not only for it’s own productivity.

New Years Resolutions

~ Adam ~ Leave a comment

I’ve never been much good at keeping resolutions, they start out strong but then quickly slide.

Let’s see if I can do better this year. Here are my New Years Resolutions:

Look at the Needs of the Business

Too often developers and development managers focus too much on the code and the features and not enough on the business they’re working within.

Mind blowing functionality is worthless if it’s not user friendly, performant, and deployed. I want to keep the goals of the business in mind and make sure that my (and my team’s) goals are aligned with them.

Dedicate Time Each Week to Learn

I’m a great believer in continuous learning, but it’s hard – particularly when there’s firefighting to be done or issues to resolve.

To help me continue to grow as a developer and a manager I want to allocate a little time each week to my CPD.

Get out the Office

I mentioned a few weeks ago The Importance of The Local Development Community so this year I want to make a real effort to attend Agile Yorkshire, Leeds Sharp and a DDD Conference!

I want to meet with clients, put in some face time, and understand how our system (both solution and business) works (or doesn’t) for them.

Find And Exploit Our Bottleneck 

If you’ve read The Goal or The Phoenix Project then you’ll have had this one drummed into you. People, teams, and businesses are systems… systems have constraints and bottlenecks, if you want your system to work optimally then you’ll need to find and exploit your bottleneck.

I want do do more work to analyse our Support System to identify the bottlenecks. It’s important for me to understand the big picture. Goldratt tells us that any improvement made anywhere other than the bottleneck is wasted effort, I need to make sure I’ve examined the whole system – customer to customer, if I want to add real value to the business!

The real challenge here will be what to do if the bottlenecks are not within the development team…

Scrutinise Our Signoff Process 

Your signoff process is your last chance to avoid walking into a crisis. Finding bugs is not about luck, it’s about procedure and diligence- I want to continue to give ourselves the best chance possible to find those those showstoppers before the customer!

 

So those are mine, what do you think? What are your professional New Years Resolutions?

The Importance of Testing Early

~ Adam ~ Leave a comment

I recently had a conversation with a Development Manager at a company based in Leeds. We were discussing when to involve the QA Team in a release we were planning, I argued that there was little value in wasting the QA guys’ time until we were feature complete. After all, everything was still subject to change and they’d only have to repeat those test again at a later date.

Ironically I now hold the opposite view.

If you walked up to me today and asked at what stage of development you should bring QA resource into a project I would always advise that as soon as the developers start coding it’s too late.

Your QAs are not automated test machines, I can crank out a few Selenium scripts to test a UI during my lunch hour! Your QA team are there to ensure that the features you deliver are the highest quality they possibly can be. So when does quality begin? I would argue in the design phase!

I’m currently working with a QA who, for a variety of reasons is trying to work out all a feature’s permutations eighteen months after the design was originally done. He’s documenting these, generating Functional Tests for them, and raising bugs where required. This is incredibly time consuming and takes lots of time from him, a development resource, and the Product Owner. Imagine if he’d had the opportunity to work this out before development work had begun!

The key here is to allow you Product Owner, QA, and Developer to create the spec together. The developer sets to work and the QA begins creating their functional tests, as soon as the feature is code complete your QAs are ready to go!

So, my original concern was that our testers would have to continue to test over and over again. Yes, this is a risk, however, when would you rather be alerted to any issues… as the developer is adding finishing touches, lining up buttons and tidying Unit Tests, or six weeks after they’ve finished? I know which I’d prefer!

This is where the distinction between Functional Tests and Signoff Tests becomes important. Functional Tests are used to test every permutation of a feature, to verify it against the spec, and to perform regression testing after substantial change. Signoff Scripts are to protect your critical functionality. Use your Functional Tests early to ensure that the newly created feature behaves according to spec, use your Signoff Scripts to verify your functionality before a release.

Get your QAs involved in your spec documents, organise your Sprint so they create tests while the developer codes, and get timely feedback on your features while you’re still in a position to fix them.

Measuring Sprint Velocity is Useless Unless You Ship!

~ Adam ~ Leave a comment

I’ve recently been reading The Goal by Eli Goldratt, in it Alex Rogo (the Plant Manager) boasts to an old teacher of his that the new robots they’ve installed have greatly increased their efficiency. The Yodaesque Jonah then promptly proves his data worthless and sets Alex on the path to enlightenment.

What struck me however was how clearly this mirrors the software industry. The Goal has been the go-to book for managers for years but only with the relatively recent release of books like The Phoenix Projext have the applications to software industries been recognised.

It’s a well established idea to model a software development team like a factory. Time and money goes in, features and fixes come out. In the story Alex was delighted that his robots had given him an increased efficiency for making a particular part of the process, it was only when Jonah pointed out that the robots did not result in any increase in sales that he saw the problem in his logic.

So, let’s imagine that our software business is Alex’s factory. We’ve brought in a robot to do the work of the Development Team and Sprint Velocity has gone up from 100 Story Points to 300. As the Development Manager you get to pat yourself on the back, celebrate your success, and go home at the end of the day.

But what happens to your release at the end of your Sprint? Is your product stacked up on your factory floor awaiting the next machine (perhaps your deployment or infrastructure team)? Or have you sold it and added value to your business?

This may seem like false measurement, your numbers are telling you that you’re delivering but the reality is very different. The truth however is even worse, unshipped features are the software equivalent of Work in Progress, they’re the half finished products sat on your factory floor taking up time and space. Until your business can deliver them they’ll continue to come back and haunt you, injecting unplanned work into your Sprints and sucking time out of your Development Team.

So, If your Sprint Velocity measurements only take into account the work pushed through your Development Team then you’re not measuring the value you’re adding to the business, you’re making the same mistake as Rogo and only considering one part of the system. You may be getting great results, but are you helping achieve the goal!?

The Single Biggest Standup Mistake

~ Adam ~ 1 Comment

We all do them, Daily Standups are the quintessential activity of a Scrum Team. Each morning the group gathers, discusses what they did yesterday, and what they plan to do today. The tone is monotone and everyone sips away at their thick treacle-like coffee in an attempt to remain upright while a few of the younger developers attempt to conceal hangovers which would force anyone of your advancing years to cower under a desk.

For me the daily stand up is one of the easiest Scrum practices to implement and therefore is often forced upon a team so they can claim that they’re “agile”.

As with many Scrum components the value is not in the compulsory attendance but in the enlightenment when a member of team suddenly has a lightbulb moment and understands why a practice is of use to them.

For me that moment came when I realised that the Yesterday and Today section of a Team Member’s speech is simply window dressing. It’s interesting certainly, it may even help the Team Lead or Scrum Master measure burndown but the real value of a Daily Standup is in the often neglected Impediments section.

During our working day we encounter and resolve countless impediments, those which prove to be more troublesome are raised in the standup where (more often than not) time pressed colleagues mutter a few words of advice or encouragement before wandering back to their own tasks.

This way of raising issues actually dampens the team members’ enthusiasm for “Any Impediments”. After all why should they raise them in scrum when they could simply ask a more experienced colleague quietly, later in the day. I know I wouldn’t want to admit I was struggling to my Team Lead if there was no increased chance of getting help.

So what do I recommend?

I suggest that each Scrum Master take a pen and paper into the standup. As well as facilitating the meeting they need to capture the team’s issues and impediments. At the end of the meeting it is their job to resolve them. More often than not this will involve finding the correct people to lend assistance, be they infrastructure guys, senior developers or management.

The Daily Standup is not a progress meeting. It’s an opportunity for the entire team to come together and check that no one is struggling with an impediment which will impact the team’s ability to deliver at the end of the Sprint.

Remember that a Sprint is not about individual completion, it’s about the team and this is everyone’s opportunity to keep the group on target so they can meet their combined goals.

Restructuring your Sprint to Produce Finished Software

~ Adam ~ 3 Comments

If your company is anything like many of the teams I’ve worked with your Sprints are a planning tool used to break down monolithic projects into smaller pieces to track progress.

In the real world big releases often pressure development teams to adopt more established project management techniques to hit deadlines. A PM will nominate a certain number of weeks for development (hopefully based on estimates your developers have provided) and then subsequent time for testing, bug fixing and UAT. The Development Manager will then allocate time into those Sprints.

But wait a minute? Doesn’t Scrum team us that we should be able to produce full working software at the end of each Sprint? If that’s the case then why are we saving all of our testing and bug fixing until the end!? It feels to me as though we’re running Sprints but ignoring the line of the Scrum book which talks about finishing a Sprint with deliverable software.

In Rolling Rocks Downhill Clarke Ching calls this GETS Software (Good Enough To Ship), it’s a term I like. In his book the team would build feature after feature however at the end of each iteration they ensured the product was GETS. That meant that if something took longer than expected or their budget was cut the team would always be able to fall back on the last version.

In a typical PM managed project I envisage features a development phase, when new bugs are carefully and painstakingly introduced. Then a testing and bug fixing phase, where they are removed.

waterfall_bug_flow

If however you commit less work to your Sprint, let’s say half the amount then your developer can spend the second week refining their work, working alongside the QA, designing upcoming features, and removing any bugs which are found.

This will obviously reduce your Sprint Velocity, however it will mean that whatever work is completed is completed, reasonably and as Clarke puts it GETS. However without the need for long and laborious bug fixing phases this time can often be reclaimed.

agile_bug_fixing

This approach is game changing for a number of reasons. Firstly your quality isn’t compromised, instead of a quality decline and then improvement your software stays at production quality. Second, should your customer, Product Owner, or business priorities change you can update your plans (maybe even delivering early). Surely that’s what we mean by Agile!?

Many thanks to FooPlot for the brilliant site I used to create these graphs and Jing for the screenshotting and labeling software.

Rolling Rocks Downhill Book Review

~ Adam ~ 4 Comments

I read Clarke Ching‘s book Rolling Rocks Downhill a while ago and I picked it up again recently while on holiday. I’d enjoyed it the first time, going back over the story a second time with a little more leadership experience I was amazed just how many valuable lessons Clarke has managed to cram in there!


The book is a Business Novel and follows Steven, the Development Manager at Wyxcomb Financials who discovers that a competing company has stolen their idea and is determined to beat them to market. Their project on the other hand is behind and likely to slip even further. With their company’s future at stake Steven must develop a new approach to development to save the day.

What follows is a story of a team discovering Agile ideas and practices for themselves.  Not because they have a guru preaching at them, but because they’re trying to solve real business problems. I couldn’t help chuckling at some of the discussions Steven has with his mother, the Product Sponsor, and even the Cafeteria Manager as he learns about Iterative Releases, Product Backlogs, Continuous Testing and the Theory of Constraints.

After all can you really understand the advantages of building a small number of features in an iterative manner if you’ve not heard about the French Fry Revolution!?

An easy read and a great book to really reinforce some of the ideas of scrum you already know with real world examples. Recommended to anyone!

Is Proper Project Management the Waterfall We’re All Afraid Of?

~ Adam ~ Leave a comment

I recently watched a Pluralsight course on Project Management for the Software Engineer. My role has changed recently and I’m finding myself far more involved in planning the team’s big picture. I hoped with a few more ideas and skills under my belt I’d stand more chance of rising to the challenge when things get tough.

Having watched the video (very good by the way, I’d highly recommend it) I came away with an uneasy feeling that this “Project Management” stuff was simply Waterfall under another guise. As developers we’ve been so bombarded over the last few years with the message that Waterfall is antiquated and Agile is the new methodology and that all notion of long term planning and detailed requirement documents must be stamped out.

Needless to say that when I watched the video explaining the importance of a proper project plan and detailed specifications I was rather taken aback.

https://twitter.com/ArdLiath/status/716650488867856388

Surely we’re not preaching a return to the old days of strict deadlines and work planned out months and months in advance?

It is at this point that I have to raise my major frustration with Agile and Scrum in particular. Everything I’ve read and every speaker I’ve listened to advocates a prioritised backlog of work which the team will work through to deliver maximum benefit to the business.  This is great for a startup, or a team developing a solution where they are continuously refining a project to deliver more and more value.

In my experience however the business process is rarely so clear cut. For example, I have a deadline looming, several customers have paid for dozens of new features to be included in our application and the sales team have committed to a UAT delivery date of the end of June. Suddenly I’m not working to a prioritised backlog, I’m working to a project deadline and failure to meet it could have serious repercussions!

So how do we combine these two approaches? How can I maintain the ownership and agile nature of a scrum team while carrying out the long term project plan necessary to ensure a successful delivery? Is it possible or are the two mutually exclusive?

Let’s look for a moment at what the Project Management approach promises us

  • A clear set of deliverables agreed by the client
  • A clear list of delivery dates for stakeholders and other teams in the business
  • Easier control by planning work up front allowing us to track progress and spot issues arising

Is there a way we can keep these benefits without sacrificing the agile nature of scrum?

A Clear Set of Deliverable agreed by the Client

Let’s take this one one first, Agile does not mean wishy-washy requirements, it means breaking down big visions into manageable and deliverable chunks. While a client may envisage a huge monolithic project it is the job of the project team to break this down into small, simple user stories which can be delivered in manageable pieces.

Where an analyst may claim that a multi-document specification contains every use case and scenario they system may encounter I’d be willing to bet significant money that they’re wrong. Furthermore, by the time you deliver this enormous project the business value for it may have waned dramatically (I’ve seen this happen myself). It is undeniably better to break your huge requirements down into components which can be delivered for continuous feedback as you go.

A Clear List of Delivery Dates

Assuming you are working in a scrum team the agile process does not obscure delivery dates, in fact it embraces them. Rather than setting an arbitrary deadline months and months in advance and gearing the resource and financial plans towards it continuous and iterative releases increase the reliability of hitting deadlines, after all – it’s less likely you fall significantly behind over a two week period than a two month one!

Use your sprint end dates as your deadlines, deliver frequently into a sandpit environment so the client can see your progress and begin testing as early as possible. Big deadlines are a lot less stressful when you’re on the nth iteration!

Upfront Planning for Clear Progress Tracking

As a Project Manager you are going to be continuous asked whether a project is on track to meet the business deadlines, I’ve not tried it myself but I’m willing to bet turning around to your client and saying “We don’t have deadlines, we’re agile…” Probably isn’t the best approach.

When we create our backlog we break our features into User Stories, each is estimated and prioritised. At the beginning of each sprint the highest priority items are selected to be worked on. From a project management perspective is that other, “more important” stories may be moved into the sprint in place of your items.

However in a business environment we need to plan releases and deliverables several sprints in advance. as a Project Manager we need to ensure that our work is completed on schedule and not simply pushed back until the 11th hour.

My suggestion here would be create a project plan which covers which sprint each User Story should be completed in, these should be negotiated ahead of time with the Product Owner. At the beginning of the sprint the work which was planned in is moved up to a high priority. On a quiet week the team may have capacity to complete your planned work as well as some of the other tasks, on a busy week your work may not be the most pressing (there may be customer support requests which take precedence for example). However, as with all things it is the Product Owner’s prerogative to decide which tasks will give the most business value yours, or the other challengers.

What this process allows is for you to plan out your control points well ahead of time. If you’re expecting certain tasks to be delivered at the end of sprints 2, 4, 5 and 6 then you can begin monitor these and verify that these targets are being hit. If they’re not then you can explain very clearly why they fell behind whether this was because a task took longer than expected or because a more pressing task came in.

This is the same process we already work in, resources can be reassigned at any time in a normal project. The advantage here is that the Product Owner formally balances the priorities of the business and gives reasons why the project must be allowed to fall behind.

Handling Scope Creep

As developers we’re constantly aware of the pressures of scope creep. A piece of work is designed, estimated and scheduled in. Then, as soon as the client sees it they have another idea and want a further feature to be added. In an agile environment we want to encourage this feedback, ultimately it helps us build software which better suits our customers’ needs.

From a business perspective this feature creep can be deadly. Budgets are drawn up and quotes delivered based on the original feature, if these prove to be inaccurate or underscoped then you are effectively delivering your service for free.

In order to avoid this it’s vital that a formal process for Change Requests is given ahead of time. If a customer feels that this is their one and only chance to refine the product to make it valuable to them then they will push and push everything into the same delivery. If however a formal CR process exists they know they can continue to work with the team and refine as they go. There’s a theme here, the emphasis needs to move away from a single monolithic and towards small, iterative and manageable releases.

In Conclusion

I believe that the two approaches of Project Management and Scrum are not mutually exclusive. In fact I believe both aspects are vital if you want to achieve anything other than a constant aimless meandering of features.

For the two approaches to work well together I feel there are few steps which must be carried out:

  • Break your project into manageable tasks and tentatively assign them to sprints with the agreement of your Product Owner.
  • Measure the progress of your project through it’s lifetime, ensure that if a task is not completed in the given sprint you understand why and stress the urgency to the PO that the ground is made up.
  • Embrace change and allow your customers to refine as the project is developed. Formalise the process and be clear that any change will be re-scoped and budgets will be updated.

I’m going to be attempting this approach in a few weeks for a release to our biggest customer. Hopefully this balanced approach will see us through.

Learning the role of Scrum Master at the deep end

~ Adam ~ Leave a comment

My induction into my informal position of Scrum Master was rather quick, a member of staff was leaving and the team needed someone to help run the meetings. Learning fast and jumping straight in at the deep end is my typical (if not favourite) way of learning so I rolled up my sleeves, read a few books and did my best.

So what have I learned? What dubious advise could I pass onto any developer who finds themself stepping into the same role?

Know your Ceremonies

The Scrum Master’s week is punctuated by meetings such as Daily Standups, Planning Sessions, Sprint Review and Retrospectives. You’ll encounter resistance to these because devs like writing code, they don’t enjoy spending hours each week sat in the meeting room. You’ll need to justify these sessions, if you can’t explain why you want to meet then it’s best not to!

Daily Standup

This is the most common session you’ll be expected to run. It’s also the most famous, many businesses claim to be agile simply because they have a daily standup! Getting it right is key to your team’s success.

First the obvious question, do you actually need to stand up? No! People who have never attended a standup will challenge this methodology, there are advantages for and against standing up for the meeting and you need to understand both sides if you want to discuss the reasons. On the one hand physically standing encourages participants to keep their part short and on topic, I also like to guide speakers around the circle so everyone knows when they will be expected to talk and no one is left stammering. On the other hand standing up can be very difficult for distributed teams, meeting over Skype with headsets reduces lot of background noise but brings with it the inevitable technical problems and opens the unending source of distractions which is a dev’s PC. There’s no right answer, but different teams will prefer one style or another.

Keeping on topic is a huge challenge and one I’m still struggling with. Your standup should consist of three bullet points

  • What did you do yesterday?
  • What are you aiming to do today?
  • Are you blocked in any way and are you on track to burn down?

In my experience there are two main reasons for a scrum wandering off topic, these are Story Telling (going into too much detail about what they did yesterday) and Problem Solving (using everyone’s time to try and become unstuck). Devs love to talk about challenges they overcame and solve other people’s problems. The key is to spot when this occurs and suggest that these conversations can be had later.

The sixteenth minute is an interesting idea, as I mentioned above one of the main reasons for scrums dragging on is people trying to utilise the entire team to solve their impediments. One approach is to formalise an optional follow up chat for the required parties so they can continue to discuss issues without hindering the rest of the team. Keep an eye on how many of these follow up conversations are needed, too many and they rapidly take over the team’s morning.

Sprint Planning

I’ve found the key to Sprint Planning is preparation, this can often be an issue when the meeting is scheduled for first thing on a Monday morning! Before you walk into the planning session you should have:

  • The backlog prioritised
  • Details of the capacity of your team (or team members if you plan individually)
  • Details of how much work has been carried over from the previous sprint

If you don’t have this information to hand you’ll need to acquire it in the meeting, this is all information you should have access to through your planning software. Asking for it in the meeting wastes everyone’s time and leads to boredom and the feeling of wasted time, not how you want to start your sprint!

Armed with this data your planning meeting is simply a matter of dishing out the highest priority tasks to the team members who want to pick them up. Simple!

Sprint Review

The purpose of the Sprint Review is to demonstrate what you’ve built to the stakeholders and other interested parties, this can often be your Product Owner, Support Team or other devs. These people then have the opportunity to provide feedback which can be considered, prioritised and included in the project.

The problem I often find is that there are so many ideas, so many discussion points and so many questions that your one hour slot is barely enough to get through the first demo. So how can we address this?

  • Nominate a single person to make note of the suggestions, by making sure everything is written down no idea is wasted and they can be prioritised and scheduled with your Product Owner
  • Consider recording videos instead of live demos, the live demo is a bane of any presenter. By asking your devs to record videos in advance the demos are foolproof, there are no unexpected technical problems and you know exactly how long each video will last!
  • Save questions and feedback until the end of each presenter. We are geeks, not public speakers, give your developers a chance by letting them get to the end before bombarding them with suggestions on how to improve the task they’ve been slaving over all week!

Sprint Retrospective

A fundamental part of the Agile Manifesto is that teams should look at what went well, what they’re struggling with and adapt their processes to improve. Often this is done in a retrospective meeting.

When I first started doing retrospectives we followed a well known pattern

  • What went well?
  • What didn’t go well?
  • What should we start?
  • What should we stop?

We worked our way around the table and everyone was expected to come up with a suggestion for each list. I found these meetings rather unfulfilling, I often felt they descended into a rant about process, other teams, technology or whatever else was irking the group at the time. While I’ve no doubt that it was good therapy I didn’t feel like the hour achieved much.

Instead I’d suggest planning each meeting with a specific topic

  • How can we ensure that high priority support requests are picked up mid sprint?
  • Should we use Web API or WCF for our new API?
  • How can we get clear acceptance criteria for our upcoming bespoke development?

By stating what you hope to achieve from the retrospective in advance you stand a much higher chance of success! Ask your team for items they want to discuss, email around your proposed meeting topic with plenty of notice and ask your devs to bring their own ideas to the meeting.
Hopefully I’ve given a few helpful suggestions for you to consider. I don’t claim to be an Agile expert and I’m still struggling to follow lots of my own advice but every sprint we learn a little more… Isn’t that the point after all!?