With a name like TEST-driven development you’d expect TDD is mostly about testing. Especially when the end result is tests. In our book Design Patterns Explained we discussed how testability (how easily code can be tested) is an intrinsic property of software and is highly correlated with good design. This is why the 1st mantra of design patterns is to design to the behavior of the objects being written. These behaviors being described as tests.
One of the characteristics of good design is that it is modifiable with less effort than poor design. So testing first give us both better design of the code & increase its sustainability-enabling emergence. This is the big difference between test-FIRST and unit testing.
But we now have the added burden of the tests which often add to maintenance costs. The cause of this is insufficient focus on the quality of the tests. An ideal test will validate only one behavior. The intent is to decouple the tests so that when one behavior changes only one test needs to change. This requires attending to the coupling of tests as future enhancements are made. Coupling of tests inform coupling in design.
A development team working in harmony is a beautiful thing. Every two weeks they get together to decide what they are going to do over the next sprint, and then they proceed to do it. Daily retros keep them on track. Guided by a product owner the team incrementally builds their product increment. A demonstration at the end of the sprint produces value and important feedback to make sure they are going in the right direction. They get better each week with retros. Magic.
Getting to this may be a challenge, however. Well formed teams may not exist and it may be unclear how to make them happen when some people are needed by many teams. Also, the culture of an organization may be such that reorganization is not an easy move.
Another type of magic is possible, however. That’s when people make agreements to get any started work completed as soon as possible and not to start work if it will slow down more important work. They make all of their work visible to each other so they can work as a team even if they aren’t dedicated to it. They continuously improve with small changes. Also magic.
Any company that has more than a few teams can find magic in both approaches, but often only approach is magic for a particular team
In the same way that we saw how value moves through our value stream, we can look at the value stream to see our challenges. The most common challenges that companies have are:
It takes too long to get anything done
work is not properly prioritized
chunks of work are too big
work takes place on too many things
there are unclear requirements
teams don’t understand the needs of the business
some people have too much to do and are constraints on multiple teams
there is high technical debt
there are many integration errors
there is insufficient collaboration
ops is blindsided and pulled in many directions
there is a lack of visibility of what is taking place
These challenges are represented in the figure below:
Showing common challenges in the value stream
These challenges usually are seen by having by having work be stuck in large queues before the step where the problem is. Lean suggests that instead of focusing on how people can work faster we should take steps to keep our queue size down. This mostly involves working on small batches, how we do our work, and how we organize our talent.
2) you can’t predict if attempts to improve things will work
But this doesn’t mean there aren’t best practices in complex systems. In fact, it means in complex systems you must look for the few best practices there are.
By a “practice” I mean something that:
1) takes little energy to do
2) simple enough that everyone can do them
3) provides value enough of the time to make them worthwhile
Here are some Agile Best Practices:
when given a requirement ask “how will I know I’ve done that?”
before starting a new task see if there’s a task you can finish or help someone else finish
have explicit work policies (i.e., have team members know what each other is doing)
While there are others, let’s consider the value of these. The first helps avoid misunderstandings. The second shortens development time. The third helps avoid misunderstandings.
All of these are clearly valuable. All too often we worry about managing big things, and overlook the little things that can make a big difference. While we can’t control complex systems, we should do what we can to avoid chaotic events.
Let’s face it. A 2 day class may be enough to get you understanding Scrum & another one might get you to understand it a bit better, but the only way you learn how to be a good Scrum Master / Kanban Team coach is by doing. This program, led by me, is designed to do just that.
In it, you’ll work through the issues that you are having with your own teams. Each week you will learn something and then apply that to your teams. Weekly Q&A sessions assist you with any challenges you have in doing this. While there is a designed curriculum, our integrated support system enables you to pick up topics in different orders while still get assistance from me as needed.
Based on Lean principles, this program will enable you to integrate the best of Scrum & Kanban. Learning takes time.
Ask yourself why take a 2-day class that covers half the material and costs twice as much and then leaves you on your own when you could be in a 3 month program working with your team and having a Scrum/Kanban thought leader helping you?
The class starts 1/18 and is only $595. Please message me for more information. See comments for more info.
There are many things I, and many other consultants believe, that are not politically correct to talk about. I am going to talk about them now. The reason is if you are a practitioner and these resonate with you, then you might want to consider working with people like me to help you get better. If you don’t want to work with me, then use this as a checklist to vet your potential providers.
Both coaching & training is more expensive than they need to be. Much of this happens because the certifying bodies control the number of trainers by quantity. Many of the top trainers in the industry have no certification by choice.
The biggest problem with the Scrum-Kanban confrontation is that neither are the right thing to do all of the time. Usually some combination of the two is best.
Intense training, except where people do hands on work is effective. True learning takes place over time in the learner’s workplace.
People need a support system that can be used to provide them insights into their own problems. Reinventing the wheel should not be required.
AFAIK our Advanced Scrum Master / Kanban Online Workshop is the only workshop that fits the above. It’s worth checking out.
Scrum and Kanban are the two most popular Agile team level methods available. While the difference between them is mostly thought to be sprint based or flow based that is just one aspect of how they differ. More significantly, they differ in how to start, how to improve and how people should be organized. They are also based on different theories of how to manage software development work and whether you need to change your roles. The differences between Scrum and Kanban in these areas is very significant and creates other differences as a result. These include the amount of discipline to use them and in which cultures they fit well.
The Differences Between Scrum and Kanban
We’ll go through these differences in a little more detail:
Organization of the team
How to start
Level of discipline required
How to improve
Theory based on
Roles in Scrum and Kanban
Scrum has predefined roles – the product owner, the Scrum Master and the development team. Kanban can work with whatever roles already are present. If your folks are attached to their roles, Scrum may cause problems.
Organization of the team
The heart of Scrum is a cross-functional team. Kanban can work with however the teams are organized. Cross-functional teams are good, of course, but if they are either not viable or it will take some time to create them, Kanban may be a better choice.
How to start
Scrum requires a start by shifting into its predefined roles and team structure. Kanban can start where you are. Sometimes a big shift is a good thing, sometimes it’s not.
The biggest differences is that Scrum uses time-boxing (sprints) while Kanban uses a flow model with cadence. That means that things are done in small batches of work while checking in with each other on a regular basis to prepare backlogs, do demos and reflect.
Scrum works best in a culture where people are looking for something to tell them what to do and where the team needs protection from outside the team. Kanban is more self-generating and based on visibility.
Level of discipline required
Scrum requires less discipline to do than Kanban since the rules and events of Scrum tell you what to do in a more concrete, specific manner than Kanban does.
How to improve
Scrum’s focus is on doing the Scrum events, following its rules while creating its artifacts with its roles. Anything that impedes you from doing this is presumed to be an impediment from achieving Agile. Kanban’s focus is on the actual work being done. It creates explicit visibility of both the work and agreements between people on and off the team. This is perhaps the biggest different between the two: Scrum focusing on its practices, rules & artifacts which presumably make the work go better and Kanban focusing directly on the work and workflow.
Theory They Are based on.
From the Scrum Guide: Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk.
Kanban is based on Theory of Constraints incorporating principles of Lean flow. Kanban is not fully based on Lean since it does not attend to organizational structure which is a central Lean tenet.
The net difference here is that Scrum works towards improving outcomes by doing regular inspect and adapt reviews to see how to improve the teams practices. Kanban, on the other hand, looks at the flow of the work and sees how it can be improved.
Time-boxing or a flow model.
Time-boxing creates a great context within which the team can get its work done. With a flow model it is up to the team to ensure they are following what they’ve said they should be doing. Flow models require more discipline to ensure that work items remain small as there is no sprint they are required to fit into.
The figure below summaries these differences.
What These Differences Mean
Our experience is that different teams have different needs. They often need a blend of the Scrum and Kanban. The fact that both are defined to be used as a whole has more to do with their proponents trying to create approaches that work for everybody. But individual companies and the teams within them are different – and these differences should be accounted for.
However, the outcomes required by virtually all teams are the same – quick feedback, collaboration, validated code, building small increments, continuously improving, … The challenge here is that even though teams are supposed to self-organize, it doesn’t mean that they can just arbitrarily pick what they want to do. Doing so will certainly lead to holes in any approach they undertake. What is needed is a method for understanding the purpose (intent) of a role, rule, artifact or event and to ensure that if substituted, the new practice manifests what the one being substituted was attempting to do.
What coaches for Agile Teams Need to Know
When teams took on Agile in isolation knowing just Scrum was good enough. But now, virtually all organizations have teams where a blend of Scrum and Kanban are needed. Even when Scrum is to be used managing the capacity of critical people can be improved with Kanban. Agile coaches now need to know a blend of the two.
This is not difficult to provide. Unfortunately, most training provide only one side of the story.
How Workshops for Coaches Need To Be Delivered
It takes time for people to become good coaches. Unfortunately, most coach training takes place in 2-4 days. Not only is not much retained, but when students have difficult in adopting what’s been learned, there’s often no one to help them. Real learning in a classroom is also difficult.
The ideal workshop needs to focus on learning effectiveness, real adoption of what’s been learned, cost and overall support. Ideally it will take place over a few months with 1-2 hours required each week. This both enables people to learn in small steps while taking little time away from their job. This can be accomplished by using online training with flipped-classroom style learning methods.
A support system should also be provided.
This is exactly what the Net Objectives Advanced Scrum Master / Kanban Online Workshop is. At $595 it is half the cost of the Certified Advanced Scrum Master course, but provides twice the content. Enrollments after the first are only $500 each. If you have embedded coaches you can get about 180 Scrum Masters go through our workshop for the cost of only one embedded coach.
How Is This Savings Possible?
Even though I’ve been working on how to lower the high cost of coaching for 5 years with advanced learning methods, this ratio of being able to grow 180 of your own coaches for the cost of one embedded coach seemed far-fetched. So here’s an analysis of why it is possible:
Coaches do not provide a support system for the people they are coaching. Most teams have the same types of challenges as others. 1 on 1 coaching is not needed to help with many of these. Solving them this way is expensive.
The use of scaled learning methods greatly increases retention while lowering costs by 80%
With the growth of Agile most coaches don’t have the requisite 10,000 hours to be truly expert
Coaches who only know Scrum well (putting a few Kanban practices into Scrum is far from knowing Kanban) precludes teams being provided solutions that require kanban. Poorer solutions require more effort to implement.
Avoids dogma and the argument of which is better, Scrum or Kanban. Both are needed.
A 15 minute chat is all it’ll take for you to clearly see why.
2) they try but can’t. A common challenge is they don’t know how to break down big epics into small stories (which is often not taught in initial scrum training)
3) at some point they give up and do ScrumBut by not following sprints. They justify not doing Scrum by claiming that they are now doing Kanban (because they don’t have sprints). But they don’t do any of the things Kanban says to do. This is like saying “we do Agile because we don’t do documentation.”
4) their performance goes down
5) Scrum consultants are brought in and management is told the problem is “well, they’re not doing Scrum, can’t blame Scrum”
6) management tells the teams to do Scrum, because Kanban doesn’t work.
The solution is to teach Scrum, when it’s used for software development, with what is necessary to do software development.
The fact that Scrum can work anywhere works against you if you get generic Scrum training instead of Scrum training designed for you.
Live training always sounds great, and sometimes it is. But except when has your teams work together, or the materials requires a lot of interaction, it’s often not the best way to do things.
Consider the following:
1. most of concentrated training is not retained and the concentrated delivery prevents you from trying things in your job & coming back into the class for guidance
2. it takes time away from your work
4. there is no method of having you learn the material over time unless your company can afford a coach
5 live training is expensive and often involves travel costs
6 you often don’t know who you are going to get as an instructor
The bottom line is it’s expensive and not always effective.
Universities have known this for centuries – spreading work out over 3-5 months. They are also adopting flipped classroom style where you read/watch something every week. Try it, interact with the instructor, try again, get questions answered and then go onto another lesson.
This is more effective and can even have remote teams learn together. The bottom line is several times more learning at significantly less cost.
If you’re interested in learning more, please message me (classes in Advanced Scrum Master/ Kanban) and Agile at small to mid-scale.
I mostly love Scrum, but I am concerned with that it:
1) doesn’t work everywhere but is promoted as if it does
2) sets up a sub-conscious resistance to go beyond it as because the case where “We do Scrum, but we do X instead of Y” is virtually always considered negative whether it is or isn’t. Also, when you are certified in Scrum and go beyond it the value of your certification is lessened
Lean-Scrum differs from Scrum in the following ways:
1) Scrum practices & roles are considered to be ways of achieving particular intentions
2) The team needs to fit into the context of the organization
3) Any part of Scrum can be modified as long its intention is still retained. This may have you no longer be doing Scrum but you should still be doing some form of team-agility
4) It considers Scrum as a tool in a toolbox with other tools being needed (e.g., Kanban)
5) Scrum mostly works iterations & cross-functional teams are advisable
6) We don’t really care if we’re doing Scrum or not as long as we’re consistent with Lean principles
Lean-Scrum is an approach where use take what’s useful and leave what isn’t.
Be clear, Lean-Scrum is not Scrum. But my 19 years of doing & helping others do Scrum has demonstrated it is more effective