Agile as I’m sure many of you are aware is an iterative development process which empowers teams, and allows for rapid development. Sounds great right?
Fixed scope, price, and time.
As a development agency, my customers often want a fixed price, fixed scope, fixed time scale project – the perfect triangle. (or an impossible triangle) and almost always end up waterall due to the need to sign off the scope to provide a near accurate estimate.
In this approach everything is upfront, specification, sign off, delivery milestones, sign off, final release, sign off and then delivery followed by yes, sign off. In the later parts of the project the word CR (change request) becomes ever more regular as the requirements are delivered, especially if they don’t fully meet expectation, with a spec there’s a base line, but often the spec has to be extensively detailed to be clear on whether the spec was detailed enough to be clear cut. The time to make a super detailed spec can be months.
The issue with this approach is the customer cannot see the deliverables until near the end, they’re often functional, and not user centric, testing is at the end, so defects are always late in the Software Development life cycle (SDLC).
Meet Agile.
In an Agile world the work is broken down into user stores, a piece of functionality. Often broken down into tasks of <1 day.
In a true agile nature, you have a fixed size team for a period of time, and build code and deliverables and at the end of each sprint, we have a product that can be deployed.
The customer defines the user stories at the start, and these are estimated, but the requirements are top level, not detailed. This is “the vision”
During the 1st sprint (or a planning-sprint), the project owner will plan the user stories, agree the acceptance criteria, ready for the forthcoming sprint. The user stories are ordered with a mix of high priority, medium and low priority items.
The next and subsequent sprint has the whole team involved. The Scrum master kicks off a sprint with a sprint planning meeting where the teams discuss the deliverables discuss the detail, estimates are updated, the deliverables are agreed and off-we-go.
As soon as a item is developed, it is tested against the test criteria, and deployed for a test team to do functional testing. Once passed it then goes to the product owner to confirm its done.
Daily, the teams meet (the Scrum) which lasts 15 minutes (max), this meeting provides an update on what did we achieve yesterday and what are we achieving today, and the most important question “do we have any blockers?”
if the velocity of development differs from the estimate, then the scrum master will propose to drop the lower priority items in preference of a high priority item and “potentially deployable code” is achieved.
The benefits of scrums increase the scrum masters and product owner awareness of velocity, the teams are involved and empowered to deliver as a team – small wins every 2 weeks.
But the workforce often have to spend time logging time, planning and attending meetings (scrum, planning, estimating, reviewing).
Agile encourages collaboration, it allows change of scope, it maintains velocity and delivers “potentially deployable code”
The Challenge
Agile works well on iterative improvements where the change is small, but where the change requires significant back office development it can be difficult to deliver “potentially deployable code” especially if the development spans multiple sprints.
All team members need to understand their requirements of an agile team.
Agile isn’t something you can switch overnight, you need to support the teams and empower them.
Before you begin you have to have an automated deployment environment, if tasks are delayed to UAT then the whole process becomes inefficient. This can be one of the biggest challenges as it requires significant changes to accomplish this.
If the team cannot estimate accurately, or the user stories and tasks are not detailed enough, and did not get sign off from the customer the same problems as waterfall exist.
Ensure your scrum master can support the team
Agile requires good communication (vs leadership), this is the role of the Scrum Master. They need to ensure the rules of the game (Scrum) are obeyed.
Agree on how you estimate.
Story points or hours, and whether you’ll use an exponential scale to reflect confidence.
In my experience you can use either, whats important is what you do with large estimate items. You need a means to reducing them especially before you start your sprint. Generally we would create a planning task in an earlier sprint to break it down, so that the next sprint has a split of items and increased confidence.
Agree your maximum task size
How big are you happy for your task to be before you expect it to be built, testable, and deliverable? We previously had this at 3-4 days, but during that time, it can become bigger in scope and complexity, so we prefer to keep tasks to 1 day or less, that way each day it should be achieved.
Be clear on what your time estimate is
If you use a tool such as JIRA your estimate may be for a task, but actually its split between product definition, development, test, and DoD. If you cannot quantify what your estimate was supposed to be for each team, then how can you know which team is maintaining their velocity.
Set your active work rate vs governance percentage.
We assume that in an agile project that 30% of the staff members time is going to be spent reporting progress, planning, and reflecting. The remaining 70% is actually doing.
Agree with your team members their responsibilities – RACI
Agree the minimum level of detail that each teams require (dev,test,product).
Template(s) for user stories and tasks
Do we need wireframes? Interaction diagrams? Written descriptions, how is it going to be tested, who is responsible for the acceptance process? What browsers do each test need to be run in?
Often its not the positive cases which are an issue, its the negative ones, validation, messaging, screen resolutions, dependancies – there should be a clear agreement on the definition used.
What stages is your tasks going to work through, and who owns it at each stage?
In agile you’re going to have a number of different tracks running at once, your product team writing descriptions, test team defining acceptance criteria(s), customers signing off, development of code, testing of code, deployments. All these items need an agreed flow of responsibility else tasks can get lost or back up on one person.
Agree your workflows up front and ensure your team understand how this will be managed.
What is the Definition of “Done”, and who is owning it?
The definition of Done is essential, what does it mean? If your detail is vague then tasks can pass tests, and be complete, but not function. What happens when two user stories need to co-exist? Is passing unit tests sufficient or does the customer have to sign off? These are essential items to the success of the project and in knowing that we don’t need to revisit this item – its done.
What do we do with tasks which didn’t quite meet expectation?
This is a follow-on from “definition of done” but is in part Change request (CR) territory. What do you do if something doesn’t quite work “I didn’t quite expect it to work like that”
either (a) Your templates and process probably aren’t collaborative enough with your customers and/or (b) it wasn’t well understood and/or (c) insufficient detail.
If and when this happens, does it go back into the sprint, is it prioritised later? these items can impact your velocity, so be clear on what occurs in this instance.
Understand who is the Product Owner
Typically the Product Owner is the customer (or a product Owner acting on behalf of the customer – a proxy), the Product Owner has to be actively engaged, not all customers can engage in this way and that has to be understood. If they choose to assign their responsibilities to a Proxy (usually a internal member acting on their behalf) the customer needs to fully trust the member else there can be issues over priorities, deliverables and acceptance.
Communication.
Communication is essential in Agile, all the teams need clear communication. Everyone need to engage, if they lack confidence they can find Scrums intimidating and not express their opinion. Identify any staff who are struggling and mentor them.
Meetings – Scrums can turn into a forum to discuss detail. BEWARE. before you know it your entire team will be discussing an issue that only a few members need to discuss. The items being discussed must be to the point (what I did yesterday, am I on track?, this is what I am doing today, do I have any blockers?), issues requires a separate meeting from a scrum.
Oh don’t forget a well done if velocity is on track or blockers are being closed off – positive spirit helps to maintain optimism and velocity.
Blockers should have an internal time-to-fix target for resolution (a type of SLA). Let people try to fix their own issues, but we need answers – we aim to resolve in 24h or by the next scrum. BEWARE scrums can end up being a to-do list for blockers. ensure the team are focused on resolving them and not reporting the same things every day.
Ensure the team suggest solutions to problems. Where blockers exist, empower your team to offer suggestions, not just the problem. Its better for the team to agree than to debate a fix – its quicker and encourages collaboration during the day.
Water-Scrum-Fall
One approach to consider is Water Scrum Fall, a hybrid. For us this is the process which we often use where a customer wants a fixed scope and cannot be actively engaged. This defines the scope as you would in a waterfall project, detailing the user stories, tasks and projecting a timeline and cost (a specification).
The project is sized with contingency as a resource model for the duration. (The buffer allows for rework, and changing requirements).
Once accepted, the sprint(s) are planned, commenced, and “potentially deployable code” is released for each sprint to UAT.
As per agile, the customer can change the scope, and in these cases the backlog size needs to be monitored to ensure its achievable within the committed agreed resources.
“Potentially Deployable Code” is rarely deployable code.
As code is deployed and merged, regressions inevitably occur, code never quite is polished, it requires a team to fine tune it, to ensure it perfect before its deployed.
I’m quite a stickler on this, and I often find tiny details which although it meets the brief, isn’t perfect, plus for go live we may have a strict set of test cases we need to manually carry out.
These items of polish can impact your team(s) velocity if its re-entered in the sprint, so its worth considering whether to pass this to a separate team to add the finesse.
Conclusion/ Take Aways
Waterfall project often fail as there’s little customer engagement until the end. CRs do not give customer satisfaction, so an Agile or Hybrid “Water Scrum Fall” are good alternatives if you can mentor your teams to work together well.
Agile projects require daily engagement, which if achieved, keeps the customer updated and empowered to achieve “potentially deployable code”. The end of sprint retrospective is a good way to improve the working relationship of all parties, but this may be a wake up if the velocity isn’t as you expect.
Water-Scrum-Fall offers a mid-way point, where the Customer can be less engaged, but confident the deliverable will achieve their goals, and priorities can be changed in a semi-flexible way.
Both Agile and Water-Scrum-Fall require good internal communication and dicipline, without it the control will be limited and you’ll face challenges but if you get these items right it can be very effective.
Scrum masters are more than just a project or product manager. They have to engage teams, feedback and own the project. Empower them.
Plan well in advance for holiday, have contingency plans in place for sickness. Test resourcing can be a challenge as their workload is often required at the end, so ensure that they are managing their “acceptance tests” for the next sprint early on.
For me, agile has built a sense of team, through regular iteration we have improved our estimation, our level of detail and test process. We continually improve and that encourages us to deliver better code which meets our customers expectations.