So, your manager just finished a SCRUM course, because your enterprise company thinks it is the cutting-edge management process and now everything should be SCRUM or something very close…
Are you doing SCRUM?
How much time do you dedicate to sprint planning?
Do you have a fixed, cross-functional and autonomous team assigned to fixed length sprints full time?
Do you have a dedicated person for managing business requirements inside a backlog?
Are you taking short (5 min per person) daily stand-up meetings where everyone shares just the blocking points to the rest of the team and the Scrum master?
Are you sure you need Scrum?
Applying a complex methodology when you are in a deep technical depth situation will just make the things worse.
It is what Martin Fowler calls Flaccid Scrum.
In this case what you really need to do first is to increment your delivery fluency starting from practices like Continuous Delivery or applying pragmatic methodologies like Extreme Programming.
For many people, this situation is exacerbated by Scrum because Scrum is a process that’s centered on project management techniques and deliberately omits any technical practices, in contrast to (for example) Extreme Programming.
Martin Fowler
Fluent Delivering teams not only focus on business value, they realize that value by shipping as often as their market will accept it. This is called “shipping on the market’s cadence.”
Delivering teams are distinguished from Focusing teams not only by their ability to ship, but their ability to ship at will.
Extreme Programming (XP) pioneered many of the techniques used by delivering teams and it remains a major influence today. Nearly all fluent teams use its major innovations, such as continuous integration, test-driven
development, and “merciless” refactoring.
In recent years, the DevOps movement has extended XP’s ideas to modern cloud-based environments.
Comparing Scrum with Lean
So, let’s say your company’s managers already read this article and its related sources, so you’re really going fast on your CI/C processes and almost everything is versioned and monitored…
How to manage that in a big company with a lot of distributed teams?
Let’s give a fast look to Lean and then to Disciplined Agile Delivery.
SCHEDULE / TIME
Agile: fixed timeboxes and release plans are used to schedule your next activities. You need to sort your activities in order to plan your tasks by priority in a managed backlog.
Lean: the schedule can vary based on priority of the tasks exposed in a Kanban board that should be always visible by every one. No need for all the team to be full time on one task, the experts can use a divide-and-conquer approach, focusing on the most critical parts first and releasing when it is possible, following the customer Service Agreements.
SCOPE
Agile: the sprint backlog will contain the minimum scope necessary to develop the next product release
Lean: the tasks are generated by customer tickets where they specify also the urgency level.
BUDGET
Agile: ROI and Burndown charts are used to monitor budget during the project
Lean: KPI and Service Level Agreement are used to continuously check product quality and the production chain efficiency
Disciplined Agile Delivery
The Disciplined Agile Delivery (DAD) process framework is a peoplefirst,
learning-oriented hybrid agile approach to IT solution delivery. It
has a risk-value lifecycle, is goal-driven, is scalable, and is enterprise
aware.
Here the differences from Scrum, Lean and Disciplined Agile Delivery.
PEOPLE
Keep the docs at the really minimum.
The traditional approach of having formal handoffs of work products (primarily documents) between different disciplines such as requirements, analysis, design, test, and development is a very poor way to transfer knowledge that creates bottlenecks and proves in practice to be a huge source of waste of both time and money.
Teams should be cross-functional with no internal hierarchy. In Scrum for instance, there are only three Scrum team roles: Scrum Master, product owner, and team member. The primary roles described by DAD are stakeholder, team lead, team member, product owner, and architecture owner.
LEARNING
The first aspect is domain learning: how are you exploring and identifying what your stakeholders need, and
perhaps more importantly, how are you helping the team to do so?
The second aspect is process learning, which focuses on learning to improve your process at the individual, team, and enterprise levels.
The third aspect is technical learning, which focuses on understanding how to effectively work with the tools and technologies being used to craft the solution for your stakeholders.
What may not be so obvious is the move away from promoting specialization among your staff and instead fostering a move toward people with more robust skills, something called being a generalizing specialist.
Progressive organizations aggressively promote learning opportunities for their people outside their specific areas of
specialty as well as opportunities to actually apply these new skills.
HYBRID PROCESS
DAD will take elements from the other methodologies to tailor a process that best suites an enterprise agile team:
- prioritized backlog from Scrum
- Kanban dashboard and limit work in progress approach from Kanban (Toyota production system)
- Agile way to manage data a and documents
- CI/CD, TDD, collective ownership practices from Extreme Programming and DevOps
IT SOLUTIONS OVER SOFTWARE
As IT professionals we do far more than just develop software. Yes, software is clearly important, but in addressing the needs of our stakeholders we often provide new or upgraded hardware, change the business/operational processes that stakeholders follow, and even help change the organizational structure in which our stakeholders work.
Agile was created mostly by developers and consultants, we need to focus more on business needs and company processes optimizations.
Goal-Driven Delivery Lifecycle
- It is a delivery process extending the Scrum one, starting from the initial vision to the release in production;
- explicit phases: Inception, Construction and Transition;
- Inception: initiate team, schedule stakeholders meetings, requirements collection, architecture design, align with company policies, release planning, set up environment
- Construction: CI, CD, burndown charts, TDD, refactoring, retrospective, etc..
- Transition: delivering in production. This stage contains steps like UAT, data migration, support environment preparation, stakeholders alignment, finalize documentation and solution deployment.
- put the phases in the right context: evaluate system preparation activities before development start and management of the system by other groups after the final release
- explicit milestones
Conclusions
Here we have seen, shortly, the main differences from Scrum, Lean and Disciplined Agile Delivery.
DAD is a very complex process and to find out the details there is just THE book to read in the final references.
A complete enterprise delivery process is something that requires months of work by an architecture board, but the point here is how to take the right direction as soon as possible, avoiding being hypnotized by buzz-words like Scrum or thinking that we are really agile just because we do a hour stand-up meeting every morning.
Start from removing your technical depth following firmly EP and DevOps practices. Then start formalizing your process methodology and make sure every one is walking on the same path.
REFERENCES:
- Disciplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery in the Enterprise by Scott W. Ambler, Mark Lines: https://www.goodreads.com/book/show/13661387-disciplined-agile-delivery
- Flaccid Scrum, Martin Fowler: https://martinfowler.com/bliki/FlaccidScrum.html
- How to calculate ROI: https://online.hbs.edu/blog/post/how-to-calculate-roi-for-a-project
- Extreme programming: https://en.wikipedia.org/wiki/Extreme_programming
- Agile fluency model: https://www.agilefluency.org/model.php