The middle manager. The useless fat of any bloated organization. They delegate all their work to other people, and then they wander around aimlessy, doing nothing at all expect worry about what happens if the delegated work doesn’t get done in time.
Being useless fat can be both rewarding and fun, but most of the time it is a difficult job. Even so, it must be done. After all, stuff doesn’t get delegated by itself..
It’s an interesting and not entirely new question. What to do with middle management in a company that is agile, stuffed with self organizing teams that in turn are made up of super-cool and smart people that don’t really care very much for authority figures who try to tell them what to do. Do we really need them around?
In an “agile organization” (whatever that is), stuff still needs delegating. But perhaps you are delegating goals and projects, instead of tasks. Less time is spent reporting against imaginary project plans, more time is spent actually creating value for the customer. Sharing information, explaining goals. Discussing possible solutions. Developing said solutions, showing them to the customer early and often.
As an agile or lean manager, I’m not really the boss of someone else. I am simply responsible for other parts of the value delivering process. I am also responsible for optimizing the process itself. I also try to inspire everyone else to optimize their part of the process, whenever that is possible without hurting the process as a whole.
My job is to protect tech people from nosy sales people, help sales people understand difficult tech people, explain to owners how a little money now isn’t always better than a lot of money later, and that more quality actually equals less cost in the long run. If all of the above goes well, the result is surprisingly often that we deliver valuable and useful software to customers who don’t always know what they need, but always know where it hurts.
Basically it is understanding, sharing and aligning goals and mindsets. And that is a really fancy way of saying that you need to talk a lot. I don’t really like talking to people very much, so I guess that explains why I spend half the time worrying instead.
It may not be very effective, but at least worried people look busy. And looking busy is important when you are useless fat.
“In Scrum we <insert Scrum practice here>, would we still do that if we switched to Kanban?”
Occasionally I’m approached by people curious about Kanban, and more often than not they are already familiar with Scrum. They may have read some brief blog posts about Kanban, but are left wondering what it’s really about. What are the rules? What do we have to change? Can we still do Scrum? Help! So I decided to write a blog post looking into some of the stuff you would usually be doing in a Scrum team. Would you still be doing it if you were doing Kanban, or would there be an alternative approach to achieving the same goal?
“In Scrum we divide our project into sprints. I’ve heard that you don’t do that in Kanban?”
The answer to this is, it depends. Many teams find it useful to establish a regular delivery cadence to either test or production, while others deliver when it makes sense to do so. The general rule is, the more often you deliver value to the customer, the better. The biggest difference is that with Scrum, all the practices (planning, retrospectives, releases) are tightly coupled to the sprint. With Kanban it is 100% decoupled, and everything is optional.
“I heard that with Kanban, you don’t do estimates. How does that work?”
There are no rules in Kanban explicitly saying that you can’t do estimates. In many situations it will make sense to do some form of estimating up front, or during a project. If feasible in your setting, we would however prefer to focus on what is important, and the assumed cost of delay . What would it cost us either in direct cost or lost revenue to NOT do this task now? In 3 weeks? In 3 months?
“I attended a conference once, and some weirdo on stage claimed we shouldn’t prioritize items in our backlog?”
In a large project you may well have tens, or even hundreds of individual items in your backlog. For the sake of argument, let’s say you have 50 items. To follow Scrum, you need to order all 50 items according to priority. This is typically done several times during the project, maybe as often as once per sprint. Let’s say that you on average deliver 5 items per sprint. So in reality, for any given sprint it adds little (no) value to order anything below the top 5 items in the backlog. In Kanban we prefer to ask our product owner “What is the most important task(s) for you right now?”. Answering that question is usually easier (and faster) than ordering 50 items.
“In Scrum we have a Scrum Master. Is there such a thing as a Kanban Master?”
In Kanban we recognize the fact that change is hard. People naturally resist anything that threatens their identity. Asking people to change their professional roles would do just that. When implementing Kanban, everyone involved keeps their current roles and titles. There are no formal roles. A basic principle is “Start with what you do now”.
“In Kanban you apparently have a board to visualize tasks, like we usually have in scrum?”
Yes, but with one crucial difference. Scrum has a lot more formal “rules” than Kanban, but they’re missing one – and it’s an important one. Limit Work In Progress. In Kanban we define a workflow, and we limit the work allowed in each state. As a result, we implement a pull process. Whenever there is room for more work in a board column, more work can be pulled from an upstream state (typically to the left on the board). Limiting WIP and pulling work prevents overburdening, reduces multitasking, decreases lead time (the time it takeS from we start something until it is finished) and increases flow through the system. It will also quickly uncover flow problems. If an item is impedimented for some reason, it will quickly stop or limit the flow of the entire system.
(illustration below stolen from Henrik Knibergs excellent post One day In Kanban land)
“That answered some of my questions, but I’m still a bit confused. What are the RULES of Kanban?”
I’m not sure there is an answer to that. Kanban is a management and change management technique that require some time to fully understand. There are few explicit rules as to exactly what to do, but Kanban will help you figure out what works for you. There’s no one right way, the context of your situation is always unique. Does it make sense to always have sprints with a committed list of deliverables? Probably not. Does it make sense to have stand up meetings? Probably, but maybe not every day in any context. Does it make sense to have a retrospective after each delivery? Who knows what’s right for you? Only you.
“So are there any rules at all?”
We have what we call principles:
- Start with what you do now (No set rules or processes. Start from where you are, and improve from there)
- Agree to pursue incremental, evolutionary change (Make a small change, see if it is an improvement, then try another)
- Respect the current process, roles, responsibilities and titles (Don’t manage by fear and force, build trust and understanding. Respect persons and identities)
- Leadership at all levels (Delegate, build trust, encourage acts of leadership at all levels of your organization)
And six core practices:
- Vizualise the workflow (Without understanding what happens, it is hard to implement change)
- Limit work in progress (Implement a pull system, typically a kanban system)
- Manage flow (monitor and measure how work flows through the system, in order to detect problems and opportunities for improvement)
- Make policies explicit (Document how the system works, thereby creating a common basis for understanding and improvement)
- Implement feedback loops (Regular collaboration and review at both team and company level is important to facilitate continous improvement)
- Improve collaboratively, evolve experimentally (Involve and inspire everyone to suggest improvements, and experiment to validate theories)
If you are ready to dig deeper into how Kanban may help you and your organization, I suggest you start by reading: “Kanban” by David J. Anderson
Now you may proceed with your day, I wouldn’t want you to miss your daily Scrum!
Customers who are unable to explain what they really need, marketing guys that make up their own stories, and project owners that won’t take the time to give you feedback during the project. A recipe for disaster.
I’ve recently discovered Prezi, an online and fun alternative to powerpoint. So I decided to make a little prezi-based blog post to test it out. Enjoy!
It’s strange how when a company grows, it suddenly fills up with people not really doing anything. So called management. I mean sure, they’re doing SOMETHING. But they’re not creating. They’re not producing.
No wait, that’s not right either. They’re producing stuff like policies. Processes. Rules. Sometimes they’re even yelling and pointing fingers. I’m one of them management types. That is, I try not to point fingers too much, but I’m quite keen on the rest of it. Well, I’m actually mostly a process guy. I happen to think they are quite useful. Rules on the other hand, that sounds a bit harsh, doesn’t it? And what does a policy really tell you, when you get down to it?
Our policy is to have policies
A policy is some kind of general principle that the employees and / or company commits to. “Never say no to a customer.” “You must change your password twice a month”. “In order to protect the environment, you are not allowed to print emails.” Stuff like that. If you are really lucky, you’re in a company where policies are defined as the stuff your boss rants about before they give you access to the alcohol at the Christmas party. He’ll say something like “From now on, everyone must work smarter!” and you will go “What does that even mean?”
To be fair, having sound policies like “Don’t share company secrets on Facebook” and “Don’t say bad things about our customers, at least not in public” is probably a good thing. But they seldom tell you exactly what to do in any given situation.
The beauty of the Process
A process is a documentation of the best known way to solve a given problem or situation. “Best known way” is the key part. That means every time the road changes, the old process no longer applies. The process must be changed with it. It also means that every time someone figures out a better way to do something, the process must reflect it. Implementing a process for the first time doesn’t necessarily mean you have to change much, or even anything at all. The process is there to document how something is done. And how it’s done right. How to update a server. How to service a car.
What’s the point of that, if you’re already doing it? Well, if you got more than one person performing any given action, it’s very likely that there are as many variations on execution as there are persons. A documented process improves the chance that more than one person is performing the action in an optimal fashion (according to the process).
Simply writing down the process the first time, will probably trigger someone going “Hey, that’s not how I’m doing it!” – and you’ll discover that four out of five guys where doing it wrong. If it’s a complicated task, the process will also help people so they don’t forget any vital part of it.
Last but not least, documenting a process is the first step towards improving it. Which is another subject, for another post (or series of posts). So I guess that’s a cue for me to stop writing, for now.
Let’s say you witness a boy fall off his bike. What do you see? What do you do? If you help the kid back up on his bike, most would argue that you’ve solved the issue at hand. But isn’t it likely that the boy will soon fall off again? And if that is the case, did you really solve the problem?
If we scratch the surface, there’s a whole range of other problems hidden behind the most obvious one. Why did the child fall off the bike? He probably needs more training in order to reliably control a bicycle. He certainly lacks basic risk management skills. Do we have an equipment problem? Perhaps the bike is of the wrong type or size for the child?
Riding a bike is basically a process. I don’t know about you, but when the rider of the bike ends up face down in a ditch more often that not, I see room for improvement.
Let’s leave the kid and his bike for now. Say a customer reports a bug in your software. What do you do? Fix the bug, of course! Problem solved, right? Wrong. Why wasn’t the bug discovered before the software was released to the customer? Your test team (if you even have one) should have prevented that from happening. So improving your test and QA process will do the trick, surely? The QA manager raises his hand: Wait a minute, isn’t the developer supposed to test his work before releasing it to us? A lazy developer must be the real problem here!
At this point you’re probably on to me. “I see what you did there,” you say with satisfaction in your voice. These are all reactive solutions to the real problem. The real question. Why did the bug occur in the first place? Lazy or incompetent developers? Maybe. Someone has created a piece of software that doesn’t work as intended. You may guess my next question: WHY?
When I find myself in a similar situation, I often find that the developer wasn’t given enough information to make the right choices during development. Let’s all say it together: Shit in, shit out. If I had a better developer, he may have recognized the turd when I shit in his hand, but I can hardly argue the origin of the turd itself.
So we have established that I’m full of shit, but how did we do that? We did a (somewhat informal) root cause analysis. As a fan of Lean and the heritage from the Toyota Production System, I like the 5 Why’s. – It’s a process where you basically keep asking why until you arrive at the real source of whatever problem you need to resolve.
The kid fell off his bike – Why?
He doesn’t really know how to ride a bike all that well – Why?
His dad doesn’t have time to teach him – Why?
He works all the time – Why?
He thinks making money for his family is more important than being there for his kid.
So there you go. Not only did you learn how to solve problems (instead of just removing symptoms), you also got a life lesson. No worries, you can thank me later. Now put down your laptop and go be with your family. And never solve another problem without asking WHY at least five times!
The guys in the agile community have been writing, talking and moaning about estimates for ages. “Accurate estimates are impossible! What’s the point? Let’s stop estimating, it’s just guessing anyway!“
Let me try to explain.
We all agree that we’re basically guessing, right? That may be the case, but if you live in the real world, you actually sell stuff for a living. In order to sell stuff, you need to have customers. And what’s the problem with customers? They usually demand to know what something costs before it’s produced. Go figure. Anyway, that means we need to estimate wether we like it or not.
A rough estimate from a developer or architect is usually the basis for a fixed price offer. If the estimate is good, you’ll make money. Sometimes it’s not, and then you’re up shit creek. If bad luck and an inexperienced developer team up, rough estimates can be several hundred percent off the mark. So why do we keep working like this?
The big problem with this transaction is trust. The customer rarely trust the software company enough to pay for a project by the hour. The history books are full of dishonest companies who have destroyed the trust in the IT industry. Now we all have to work hard in order to regain that trust. You need to convince each and every customer that you actually want to add value to their business by creating great software. That’s what we’re all about. Right?
If you gain enough trust within your market, I strongly suggest that you attempt to operate with budget limits instead of a fixed price. Agree on a minimum scope, and explain to the customer that you will do your best to include as much functionality as possible within the budget you have agreed upon. This way you reduce the risk on your end, and the customer doesn’t have to pay for the built-in risk premium of a fixed price. A better deal for everyone.
Great stuff, happy campers all around! Now we can stop estimating and focus on real work.. But wait a minute. How can you (or the customer) know wether the project will be worthwhile? How do you establish a reasonable budget? When presented with the required time to market, how can you tell if you will be able to deliver on time? You guessed it, by estimating. Seems like there’s no way to win this game.
To make matters worse, the game changes as you go along. As your company grows, your development process will change. You add quality assurance, you add a project manager. Your team grows, and suddenly lots of time is spent talking about how to do stuff instead of actually doing it. Challenging SLAs means more time spent on release management and server maintenance. The environment surrounding your team changes all the time, and the correct answer to “how long will it take to..” changes with it.
At the end of the day, an estimate can never be more than an educated guess. But fear not, all is not lost: If you manage to build a team with focus on quality, keep the turnover low and maintain a stable, honest environment with room for making mistakes – you might just end up with a bunch of guys that are amazingly good at guessing.
I’ve got a list of what I try to focus on as a CTO and project manager. On my list I’ve got 7 items. Project management is number 5.
Project management. Some dork in a tie running around while he’s pointing at his gant chart and yelling at people to work faster. A gant chart that stopped resembling reality before it’s even printed. He has never delivered a project on time. Ever. Everyone knows projects are always late. There’s always some delay or scope creep or useless third party vendor with a product that doesn’t work. So why even bother?
But wait.. Does another breed of management exist? Living in a touchy feely world, where projects actually deliver value, on time? And if they had a list, would it look anything like this?
#1: Be there for your project team:
Care about their problems, and help them resolve them. Your role is to remove any obstacle, and for the love of God, make sure you’re not an obstacle yourself. When they’re working, stay out of their way.
#2: Quality assurance:
Most project managers (myself included) spend too little time focusing on what is actually being done. Are your project output in tune with what your customer expects, and does it create actual value? Cost. Scope. Time. There are always someone trying to make you do more for less. Tell them to stick their project triangle where the sun doesn’t shine, and replace it with Quality, Quality, Quality.
Effective projects depend on good processes. Strive to be better. Lock into a lean mindset where you continously attempt to improve the way you and your team work, and eliminate waste.
#4: Customer service (and zero tolerance for incidents that negatively impact the customer):
You must always be available to your customer. You need make sure they know what to expect, and when they can expect it. Oh, and the last part of this rule I stole from my previous boss:
Me: “We’ve got a bug in production!” My boss: “Does it affect our customers? Forget what you’re doing and fix it!” Me: “Now?” My boss: “Are you still here?”
#5: Project management:
Is everyone and everything on track? Has important milestones been met? Do all stakeholders have the information they need? You know the drill.
#6: Sales and marketing support:
Don’t forget tomorrow. Another day, another project. Your support to the marketing division will help them make the right decisions based on your input. This ensures that the next project they’ve got cooking gets a reality check, and thereby is granted at least a moderate chance of success.
A gant chart is a great visual aid to help the customer understand when you will deliver project output. As a management aid it is more or less useless. Plan 1-2 weeks in moderate detail (not in gant chart!), 2-3 months as a rough draft to know how many resources are booked and how many (if any) will be available for additional projects. That’s it.
So, there you have it. Is this a perfect list? Far from it. Do I even follow it? Not always.
But no matter how busy my day gets, I try to keep at least #1 and #3 on my forehead. And the rest in my back pocket, for safe keeping.
How about you?
Today I spent the entire day in a room full of people, going through 16 pages of user stories with a customer. A week ago they had never heard of user stories, let alone written one. They absolutely loved it. They understand what they want, we understand what they want, and we’ve now got an excellent set of requirements for the system they’ve hired us to build.
Having your customers tell you what they really want can be challenging, having them write a set of formal requirements can be impossible. In large part because writing requirements is difficult, and people basically don’t know how to do it.
Luckily, Mr. User Story is here to save the day. Many customers have no prior knowledge of user stories, so you need to sell the concept. You need to explain why user stories rule. They’re high level, they focus on functionality instead of technology, and they’re easy to read wether you’re an engineer or a paperboy.
Below is simple how-to, hopefully it can help your customer grasp the concept of user stories.
Begin by setting up a list of known roles that are in some way interacting with the system or product to be built. Examples could be “End user”, “Administrator”, “Sales manager”, “Economy” etc.
The user story – introduction
The actual requirement should be formulated as something we refer to as a “user story”. This is basically a sentence formulated in a particular way. The point of this sentence (or story), is to ensure that the solution to the requirement will provide actual value to a known person or role. We need to understand who has a problem, what the problem is and why it is a problem.
As a <role> I want <goal / desire> so that <achieved value>
Confused? I’ll explain in a second – let’s just go through the document setup first.
Segment the document, don’t just list 50 user stories in a row. Sort them by functionality, or possibly by which part of your company that will be using the result. How many stories and how detailed you make them is up to you. You should probably spend more time on the stories that are most important to you now, and then we can build on the rest later on. You’ll want to order the stories roughly by priority as well. This way you’ll spend most time on the most important requirements when discussing them with the supplier.
The user story – why and how
The goal of the story can be very specific, but it’s often better if it’s not. It may be best if the story doesn’t tell us HOW to solve the problem. Don’t worry about the solution, or ponder about technical challenges. We need to know what you want and how, let us figure out the best way to solve it. Focus on defining the problem and explaining what value is gained by fixing the problem.
Example #1: A circular story (not so good)
- As a book store owner I want an SMS platform, so that I can send text messages
Example #2: A concrete story (better)
- As a book store customer I would like to receive a text with a tracking number, so that I know when my books will arrive.
Example #3: A generic story (even better)
- As a book store owner, I would like an effective way to communicate order information, so that I can reduce the time spent following up my customers.
The first story isn’t very helpful. Why do you want to send text messages? Who do you want to send them to? The second example defines a specific role with a specific problem, and clearly explains how this will add value. The third example also tells us what the goal is, but contains no specific information about how to solve it.
The second and third story are both okay, but may lead to different results. The second example will probably lead to a solution using text messaging to communicate, and it may be limited when it comes to what kind of information we can send to the customer. The third example doesn’t limit the communication form to text messaging, and is also more high level about what kind of information we can send.
Also note that the defined role is different in example #2 and #3. It’s basically the same goal, but example #3 focus on the role that has most to gain from the story. It’s great that each individual customer can receive a text message, but it’s even better that the book store owner can reduce the amount of manual work involved in her business. Example #3 does a better job of explaining how we can reduce cost and increase value.
So, is example #3 perfect? Not without more detail:
Additional stories and requirements
To help detail a user story, you may need to add additional stories and / or acceptance criterias below the first one. The main problem is to understand when to stop. For larger projects, the number of stories can become unmanagable. Stop as soon as all parties have a broad understanding of the problem at hand, and all high level requirements have been addressed. If you are lucky enough to have a customer that accepts an iterative process, you may proceed with mockups and prototypes to get the final details right.
Congratulations, there is now a reasonable chance that the result of your effort will match the expectations!