SKRAM
29 November 2023
Fast Agile with less ceremony
SCRAM is a hybrid between SCRUM and Kanban designed to work better with remote or disparate teams. It does away with processes that confuse people (story points anyone?) and tries to remove the religious ceremonies and focus on the vibe :-) We don’t anoint a Scrum Master either, since their role has been confused with project manager far too often. We’ll settle for Team Lead whose job it is to help the team, they’ll have responsibility for solving blockages, such as missing information. As per traditional Agile, the Team Lead role can be shared or rotated through the team.
Essence of SKRAM
As open as possible:
Communication and openness is the key to success in life. The moment you lose real openness, and silo information, you’re making it very hard to succeed. The quickest way to demotivate a team is demonstrating a lack of trust, and not being open does exactly that.
Openness leads to good communication.
|
Have you ever had to wait while sharepoint asks a manager for permission to access a document? Then had to do that every time the document gets updated? Were you disheartened? Sure, you need controls, but you need to trust your team too. |
Asynchronous processes:
Ceremonies with everyone in a room are for special events, reduce meetings to events where a solution, outcome, task list can be created quickly with less confusion.
Promote good documentation first:
Good documentation of stories and end to end goals and use of links removes the need for synchronous communication.
-
DO NOT USE WORD or any other word processor. Wiki’s and asciidoc/markdown promote content over style. Documentation should be minimal friction to get ideas across.
-
DO NOT USE TEMPLATES as they lead to information poor content. i.e. default content in templates. You can use prompts for specific information (sometimes called scaffolding) if it is always required.
-
DO NOT stick everything in a table. Tables are for tabulated data, not structure.
Promote automated tests and test-driven work:
Use tests as the basis of documenting and defining Tasks, Stories and Features.
Daily Stand-up:
A daily stand-up that is short and to the point is essential for team communication. You need to pass on the base info of what you did yesterday and what you’r working on today, that’s enough. A "Stand-up" can be async in chat where time zones are an issue, but try to have a synchronous stand-up where possible, even if not every day.
Continuous retro (it’s just story discovery):
A board with columns “Arrgh!”, “Woo!”, “Try…”, “yup” and “nup” when something shits you put an Arrgh! story in the Arrgh! column, the argh story gets suggestions which you can “Try…”. If Try… works put it in the Yup column, else the nup. Woo! is for things that are working well, and a story/use-case where it worked well. Yups/nups get put into doco.
Sliding sprint window:
look at what was completed in the last two weeks to determine velocity on a daily basis, which can be graphed to see if there are issues.
Estimate gut feel:
To estimate a task, all people in the team give a gut feel of how long this would take in days, do not over think it. Average the teams individual estimates, that’s the number.
You can estimate what will get done using how many estimated days got done in the last sliding window period continuously, and graph it. (you can now overlay the graphs)
Kanban backlog but:
Use a backlog of prioritised tasks, but we define how tasks get on the backlog to be another work flow (or kanban board set of states):
Story development → task analysis → estimation → priority → backlog. (see To the backlog!).
The whole team is expected to have input (work on) all the pre backlog stages. Time should be set aside regularly to do this, though when starting out you may need to spend most of your time doing this.
Dev workflow
Basic Task states are:
Backlog ↔︎ in progress ↔︎ stuck → done (done means tested)
The in progress state has sub states:
Developing tests → Developing solution → Reviewing → (repeat or done)
|
Stuck tasks can be sent back to the Story development pipeline if developers discover a problem. |
Continuous Cycle
Day to day developers pick tasks from the backlog and do them. They should mostly pick the highest priority task.
As mentioned above, regular time should be set aside for getting Stories or Ideas to the backlog and contributing to the other machinery like Continuous retro. I’d suggest trying things like an hour a day, or picking a job off the Story development pipeline alternately with backlog items.
To the backlog!
Why another process?
Once someone has had an idea and put up a story, how do we get that to a state that can be turned into something tangible? Whose job is it?
This job is hugely important to most teams and organisations, and it answers the questions that we always ask:
-
what makes it worthy of doing?
-
what does it involve?
-
is it even feasible?
-
how important is it compared to other things?
-
how long might it take?
Ask any of these questions up front to a team member and they’ll say “um… I’ll get back to you,” because it involves actual work. They may just say “a couplaweeks” because they’re sick of being dumped with working out what the hell you want done.
This work is often forgotten, and it has to involve what is called the Product Owner in scrum, they have to work at it, and be guided. This bit is iterative and “owners” often want it over and done with (just…. do it!) so they’ll schedule a meeting to “get it done.” What they don’t realise is; discovery is a journey, and we’ll need to ask more questions, even after we’ve started work.
Whose job is this anyway?
In larger organisations “Product Owner” is a misunderstood term, because “I don’t own it”, or “this part of the app is another departments responsibility”. So what can we use instead? Maybe it’s not one person?
We like one person to be a product owner so we don’t have to deal with lots of people and have meetings and what not (just like the manager who just wants it done). But we need to deal with people because… that’s the job, that’s every job. So lets see, we have:
-
The person who had the problem
-
The person who has an idea to “solve” the problem inside your product’s context (The Story)
-
The person who has responsibility for the product, and the vision of what it is and is not. (ie. the owner)
-
The project manager if there is one.
-
Contributors.
In the above each “person” could be multiple people or a community, especially in open source projects. Contributors are very important and shouldn’t be forgotten, they provide vital feedback that should not be ignored. All these people are stakeholders. (The person who had the problem and the Contributors are often referred to as the Users, I’m avoiding this terminology because Users have multiple roles)
This is a process of communication and education. We’ve had Business Analysts (BAs) whose job it is to interpret business requirements and document into something like Enterprise Architect, but inserting that person is an abstraction layer, “Business” becomes a noun, and they are not exposed to the realities of the “Devs”. “Business” lose touch with the product and continually try to get new graphs out of people to understand where we’re up to - i.e. they don’t know what we’re doing, and why something doesn’t work. They don’t understand their own product. However, BAs document requirements which is really good.
So, Whose job is this?
Everyone. The person who has responsibility for the product (vision) should drive it in conjunction with the developers.
How?
What we want is the most direct connection between the stakeholders and developers. It’d be great if it could be asynchronous to allow for remote workers, and inspiration. We definitely need documentation, and that should be directly from the people who understand what needs to be communicated.
A Wiki or Task could be used to drive this process. Document the story as simply as possible, have a question and answer section, a conclusion or solution that links to the story, a breakdown of steps to implement, estimates and a vote. Information about what “done” looks like and who will review the story when done.
The states of this process are:
Story development → task analysis → estimation → priority → backlog
Story development
Story development is where we ask questions about the problem to understand the proposed solution. We ask the owner if this fits the vision and provide feedback. Apply You Ain’t Gunna Need it liberally here and come up with the minimum viable solution to put back in front of the Contributors. You may need to split this into multiple stories and iterate.
|
This is Agile. People often don’t know what the solution should look like. Get something out to them in a working form ASAP and get them to try it, then improve the solution. This feedback tells you what is important. This approach gives you the best solution for the money spent at any stage in a project. It does not guarantee that the solution will be the right one, Contributors might see the solution and change their minds, but you’ve spent the least possible to get there. |
Task analysis
Task analysis is where you break the story down into tasks required to get it done technically. These are bite sized bits of work one person can get done in under a week. Tasks may be done in parallel.
Estimation
Estimation is where all developers, reading the documentation, give a gut feel for how long in days it would take to do each task - we take the average as the estimate. We do not question the estimate or force developers to rethink these based on business time lines. This is an estimate, which is a guess, which is from experience. We will see how good the estimate is.
Priority
Once we have the estimates it is the owners responsibly to co-ordinate a priority for the story. They could take a vote of stakeholders perhaps, but what they say goes.
Once all that is done, it goes on the backlog for development, where developers can pick (by default the highest priority) tasks to do.
Do we need a Project Manager?
Do you need a Project manager? That depends on the constraints.
For arguments sake.[1]
-
Let’s call a Project something that has a set deadline, set of things (e.g. features) that must be done, and a set budget.
-
Let’s call a Product something that has a set budget or deadline and a purpose (problem definition and vision). A product may be further developed.
Both a Project and Product have a budget, but a project needs to deliver a minimum set of requirements within it’s budget and timeframe.
A Project needs a Project Manager. A product does not.
A classical Project Manager manages resources to provide a fixed outcome that fails if it isn’t achieved within the timeframe and budget. Timeframe, features and budget are fixed. Projects fail by this definition a lot. Projects often fail to provide a solution to a problem since the features tend to be fixed so that they can be project managed. Change anything and "all bets are off!"
A Product can have a Project Manager, especially if you have multiple teams. Their job is to co-ordinate people if you are badly structured and silo areas of concern. They’re basically a dependency manager, where a Gantt Chart could be useful.
|
People often say just throw more money at it to get a job done by a certain time. That rarely works due to the exponential increase in overheads like communication, management, learning curves, and team building. If a project is already running “late” it’ll run later if you double the size of the team now. |