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 looking at the value stream helps you observe how value moves, looking at the value stream helps you discover challenges you are facing. Here are some of the most common challenges.
- It takes too long to get anything done
- Work is not properly prioritized
- Chunks of work are too big
- Too many things are in work
- 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
Often, these challenges are apparent when work is stuck in large queues just before the step where the problem is. Lean suggests that instead of focusing on how people can work faster, you should take steps to keep queue size down. Usually, this involves working on small batches, how you do work, and how you organize talent.
The two major lessons of complex systems are:
1) small events can lead to big challenges
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 way in which they differ. Other significant differences include how to start, how to improve, and how people should be organized. They are based on different theories of how to manage software development work and whether you need to change your roles. And this creates other differences such include the amount of discipline to use them and the cultures in which they fit. Continue reading “Why Agile Coaches Need to Know Both Scrum and Kanban”
1) management tells teams to do Scrum
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: Continue reading “Why I’m So Into Scaled Learning”
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