Is there room for functional managers, such as development and test managers, in agile organizations? Maybe. It depends on whether they take the role of an agile manager.
If you have organized as a feature teams-based organization, the functional managers (development, test, analysis, whatever) can take these responsibilities:
- Develop trusting relationships with the people on the project team, and in their function.
- Provide coaching and mentoring opportunities for people.
- Provide communities of practice for the people.
- Remove obstacles for the people and team.
- Start and nurture the hiring effort whenever you need to hire new people.
- Help people with career development.
- Provide feedback to people, and help people learn how to provide feedback (meta-feedback).
- Provide coaching and meta-coaching when people want it.
- Help the organization understand its capacity and make decisions about the project portfolio.
- Help influence the rest of the organization with the agile culture.
Functional managers are champions for the team, and shepherds for the process. They are servant leaders.
Here’s what functional managers do not do:
- Have status conversations. If the team is agile, the team understands its status. If you need help seeing their board, that’s a problem the team needs to solve. If they need help seeing their status, they need to change their board or their process for updating each other.
- Move people on or off teams, once you or the team establishes itself.
- Ask people to do something the team has not committed to, or that the product owner has not added to the kanban board. That’s right. “Your” team doesn’t work for you; the team works for the product owner.
- Micromanage any part of the project work. Or, manage any part of the project work.
What does this mean? It means that the team members are leaders. Agile pushes responsibility into the teams, and away from traditional management. Agile requires leadership at all levels.
Agile challenges managers to recreate their jobs. An agile transformation requires managers work in an agile way, and work differently than before.
If you want to learn more about the role of leaders and managers in agile, join Gil Broza and me at The Influential Agile Leader, either in San Francisco or London this year. We still have an early bird price until mid-February. Don’t miss this opportunity to help your agile transition and your career.
Next Tuesday, February 10, our TeamStart webinar series will answer your questions about "Writing Great User Stories." Whether you’re just getting started with Agile or consider yourself an expert, join us to get and give some good Q+A. We’re going to talk about writing compelling stories that focus on business value. Here are a few questions from past "User Stories" webinars:
- What are some tips for writing a great user story?
- When do I break down user stories?
- Who should drive the definition of acceptance criteria?
Here's a preview of what you'll learn in the TeanStart webinar.Tips for Writing a Great User Story
A great user story has three areas of focus: Who, What, and Why. A great user story is also written from the perspective of the user (hence the name); and a great user story "tells a story" about what that user wants to be able to do, and why (for what outcome.)
Who: Define the person who receives value from a new user story. For example:
As a user of the website ...
As an internal team member ...
What: Indicate what needs to be delivered, from the perspective of the user. For example:
... I want to purchase my items with a credit card ...
... I need a new testing infrastructure ...
Why: Show the value the user gains from the story:
... so that I have a convenient and secure way to pay electronically.
... so that I can prepare for the new test requirements of our organization.
When the estimated size of a user story exceeds the total velocity available in a team’s iteration, the story cannot fit and must be broken down into smaller stories. User stories can be broken down multiple times as they move up the backlog -- transitioning from a large, loosely-defined, parent story into a set of small, defined, child user stories that make progress towards the overall goal.Who Should Drive the Definition of Acceptance Criteria
The entire development team assists the product owner in creating acceptance criteria. Product owners represent the business and stakeholders, and communicate the needs of a story to the team. Teams communicate with the product owner about what implementation methods are possible, and how a story may be completed to meet business needs.
What are your questions? Get them answered. Join the TeamStart webinar series on Tuesday, February 10th, to learn about "Writing Great User Stories."
They’re young, passionate, excitable, humble and open. They’ve few preconceptions about how things should work and a hunger to discover how things can. I fell into this, and old friend suggested we talk. They wanted to explore ‘Agile’. We talked principles, they asked for answers, I suggested experiments.
We’ve been exploring together for half a day a week for 4 months now. I swear I’m learning more from them than they are from me. What’s emerging is collaborative, but that was nothing new to them. It’s reflective, it’s experimental, it’s visual and it really does seem to be seeding itself into all parts of the organisation.
They’ve embraced story maps and product canvases like I’ve never seen. The office is plastered with them stuck to the walls on magic whiteboard sheets .
This isn’t a software house, it’s a creative agency. They have epic WIP, variance and cycle time to tame. They’re measuring. Every week we discover new data that we can act on. I’m building them tools to visualise and share that insight throughout the teams. We’re searching for the levers that will take them to their very clear goals.
After spending years celebrating a team that stays together and continuously improves, I’m loving the excitement of something more chaotic, with less baggage and seemingly so much potential.
Oh and I get to write them code, I’m loving that more than ever.
Don't blindly adopt anything.
Scrum is comprised of a self-organizing team that is given a challenge, and to meet that challenge, works in short, time-boxed iterations during which they meet daily to quickly synchronize their efforts.
At the start of each iteration, they meet to plan what they will accomplish. At the end, they demonstrate what has been accomplished and reflect on how well they worked together to achieve it.
That's it. Anything else—release planning, burndowns, and so on, is optional. Stick to the above and find the local optimizations that fit your environment. No expert knows more about your company than you do.
I’ve spent years experimenting with how to teach kids programming, mostly using Scratch. But now we’ve found a new favorite: LearnToMod! Kids love Minecraft, and LearnToMod is entirely based on Minecraft, so it’s a perfect match!
We now do a Mod Club every Saturday evening, my older kids (9 & 11 years old) and some of their friends. It’s basically a programming school based on LearnToMod and Minecraft programming. Reeeeaaaally fun, the kids go wild (OK, me too)! AND they learn lots while doing it. To them it’s ”magic powers”, not “programming skills”.
I made a 5 minute video showing how it works:
LearnToMod provides almost 200 small programming lessons, starting from Hello World and then moving on to loops and functions and variables and all kinds of stuff. All lessons have really clear instructions and almost all of them involve something actually happening in the Minecraft world, which keeps it exciting. So kids can be pretty much self-guided, with just a little bit of support.
As you progress you earn badges and points and other rewards, like inspiring video clips and things like that. It really does a lot to keep you going!
Last session we did a Mod Duel. The three kids got 30 minutes to prepare attack scripts against me (not allowed to use direct kill commands, but other more creative ways of attacking me, like burying me in sand or conjuring a prison cell full of monsters and teleporting me in), and I wrote defense scripts. Basically a duel where we only can use our “magic powers” (programming skills). I managed to survive one whole minute, not bad!
We’ve added another slight twist to our Mod Club sessions: a Lego house (yes, actual physical plastic bricks). Each kid has their own color, and on each completed lesson they “earn” a Lego brick in that color and use it to build on the house. That way, the house becomes a visual progress meter for the evening. This serves as a subtle reminder to keep doing the lessons and not spend the whole evening just goofing around. Goofing around is a great way to learn too, but some lessons are needed to learn new concepts (like loops, or parameterized function calls), and extend your magic powers!
Here are the kids proudly displaying their house from last session!
… and then back to programming:
Give LearnToMod a try! It works for grownups too :o)
Guest post from Daniel Gullo, Apple Brook Consulting
You are talking with two consultants about how to transform your organization into an Agile development company so that you can go faster and keep ahead of your competitors.
You explain to them that your stakeholders have a need to know what is going on and to that end, there are reports that need to be created. Furthermore, your product is governed by Sarbanes-Oxley controls, which absolutely MUST be followed. Funding for your projects is allocated two to three years in advance and is based on detailed estimates, which are in turn derived from the Work Breakdown Structure (WBS) for the project. None of this can change.
You continue to explain that the teams are geographically distributed across four continents and 10 time zones and that restructuring the teams and bringing the teams together, even just for release planning is not possible. Your organization also has no budget to buy things like webcams, additional monitors, team rooms, or even open wall space.
The ScrumMaster in your organization will be “in charge” of 10 to 15 teams and may have other responsibilities as well. Also, the “Product Owner” is really in charge of an entire business unit and won’t be writing any User Stories, so the business analysts will need to be a “Product Owner Proxy” for each team.
After spending 20 minutes relating all of this (and more) to the consultants, including how none of this is negotiable, you ask, “So, what are your thoughts on the best way to implement Agile development here?”
There is silence.
After what seems like an eternity, one of the consultants clears his throat and says “Agile development is NOT for you.”
Did you really just hear that??? Doesn’t this guy get it? Is he really so independently wealthy that he is going to throw away the money that is on the table??
There’s a saying that goes: “If you didn’t get the joke, then the joke was not for you.”
If your company is not open to change or trying new things or running experiments in order to learn, then, Agile is NOT for you.
If your organization is not interested in having happy employees by focusing on people or they aren’t willing to make an investment in tools or to look at simple measurements of customer satisfaction such as the Happiness metric or Net Promoter Score, then, Agile is NOT for you.
If you are not willing to explore what “possible” really means and thus, have an open mind to doing the unconventional, then, Agile is NOT for you.
I’m sorry. I really am.
Agile is not magic. We can’t produce something from nothing or make other trade-offs go away. In order to get X, then you must do Y. You can’t expect to maintain the status quo AND improve. It’s simply not the “real world.”
Agile is all about embracing the uncertainty of change and learning how to use it to your advantage.
As a consultant, I often test the waters a bit when going through the discovery stage with a new client. I might say something that represents a “worst case” scenario to see if they are prepared to go there if it comes to that. I also ask a lot of questions around seeing how they think about people, constraints, etc.
My educational background was in Law. I am inclined to look at possibilities. I often find myself in a workshop or training session orating as if I were in court:
“In your expert opinion as a Senior Software Developer, is it POSSIBLE that you could build production-ready features, albeit very small slivers, that are capable of functioning from end to end by cutting through the entire architecture?”
“No. We can’t produce anything of value in less than six weeks.”
“So, it’s NOT POSSIBLE to release a single field on a webpage with a submit button that applies some business logic and then inserts a value into a table in a database that only includes that field? That’s absolutely NOT POSSIBLE??”
“Um, well, yes.”
“I rest my case, your honor.”
Becoming Agile means being open to possibilities and options.
In a sense, BEING Agile is like acknowledging and understanding what innovation truly means in the same sense that an artist understands what “creativity” means. Is someone who simply slaps paint on a canvas with no understanding of what they are doing considered an “artist?” Most of us would say that they are not.
Likewise, I can explain the agile values, principles, practices, and dynamics of agile culture to someone, but I can’t tell them how to be innovative. That’s something that has to come from within.
It’s uncomfortable, change.
And, through discomfort, we learn and grow.
If you are comfortable with how everything is going, then you aren’t learning.
If you aren’t comfortable with the prospect that Agile is going to make you uncomfortable, then sorry; Agile is NOT for you…
“A tool enhances our ability to achieve a certain effect (…). A hammer is good for sinking nails but a poor way to drive screws”
From Don Reinertsen’s “Managing the Design Factory”
There is no need to say how crucial it is to use proper tools in order to achieve specific results. Just like in above quote, we need to bear in mind that if we use a good – or rather, the best tool, it will “enhance our ability to achieve a certain effect”.
It’s not a rocket science but highly important rule. If you’re running a project you need to find the best tool that will help you to manage your projects efficiently. It’s also important that ‘the best tool’ that you’ve found should be as simply in use as possible. You don’t want to waste your time to understand how this tools works. Do you? Instead, you want to use it here and now!
That’s why we’ve created tinyPM – simply, intuitive and smart agile collaboration tool.
Here you can find a sneak peak to some great features:
A place where you product vision takes shape. TinyPM not only lets you create your backlog but what is more important, it allows you to groom it. Reorder your stories with drag and drop, sort them, filter. Quickly tag many stories, change their colors. Edit story details through in-line editable fields.
It is a place closest to a white board on your wall. This is where things get done on a daily basis. You can shape your flow as you like, starting with the three default states we give you. Feel free to add more and take control over your board!
It’s up to you! Move them around, leave comments, assign as many team members as you like. This is a place where developers rule and we make sure to help them do things fast.
tinyPM gives you more than just a post-it note to write on. Swarm over user story, discuss it, attach details, tag it (if it’s hard to split product into a hierarchical structure, give it more dimensions), use different card colors and feel the power of visual management.
Different job may require looking at your data in a different way. When you start your project and plan ahead the things look different than when you are in the middle of your work. We understand that and provide you with customizable view options. Choose between cards and tables, change zoom level to hide or show more details. Switch between 1-column and 2-columns view whenever you need.
In order to get all of tinyPM awesome features go to:
We get a lot of questions about how Crisp works and why, especially from other consultants looking to create something similar. After many years of experimenting we’ve converged on a model that works well, basically the sweet spot between being an independent consultant and being an employee. So we decided to open source it.
In January 2015, at Crisp Hack Summit 10, Mats Henricsson, Henrik Kniberg and Max Wenzin huddled up and created the first version of the open-sourced Crisp DNA. It is published at http://dna.crisp.se/
The Crisp DNA is version controlled using Git and both Crisp DNA repository and Crisp DNA web site is hosted at GitHub using GitHub Pages. The web site is a bunch of static web pages and images that is generated from Markdown and Textile files using Jekyll. This is the same setup that GitHub themselves use.
By using open, version-control friendly formats such as Markdown and Textile, we hope to benefit from the open source community which can fork our model, make changes and perhaps suggest improvements. This can actually change how Crisp works!
On the Rally Flowdock team, everyone does customer support. We don’t have dedicated support people. The people who respond to firstname.lastname@example.org are the ones who develop, market and lead Flowdock. This is surprising for many. We often receive requests to “pass this message on to the development team”.
Shouldn’t a software developer spend their time building a better service, not handling customer support? More generally, shouldn’t people spend their time on what they were hired to do, and not waste time doing support? These are common thoughts that lead to the creation of dedicated support teams, outsourcing customer support. We find this to be a detrimental, even dangerous practice. Having the whole team do support is crucially important for many reasons, outlined below.Feel for Your Users
Increased empathy for your users is the most obvious benefit. There’s no better way to understand users than by having a constant line of communication open with them. Even if you dogfood your own product (as we do, heavily), you’re still looking at it from one perspective. What seems like a minor bug may be extraordinarily frustrating for some, while a small new feature can be tremendously beneficial for others.
Having the whole team interact with customers leads to a surprising benefit: a shared understanding. We rarely have disagreements about what we should work on next – the team simply knows which features will provide the most benefit for our users.Communicate with the Ones Responsible
When you’re solving a problem with a user, you often have to dig into parts of the product that you aren’t familiar with. You might have intricate knowledge about how your product’s integrations work, but be clueless about the signup process. When you start helping a user who is having problems signing up, you force yourself to expand your expertise. This leads to everyone on the team having a better understanding of the product as a whole.
This is great for users as well. When they have an issue, the foremost experts on the product – the people who designed, built and thoroughly understand it – are the ones answering. Instead of having to look for answers or delegate problems (aka. handovers, see below), the responder often provides a knowledgeable answer, quickly. And if not, they can ask for help in the team’s flow.
We’ve received lots of positive feedback about our customer support. Users appreciate being able to talk to the ones responsible for a product.Chat as a Bug-tracking System
Unless a lot of effort is spent grooming its contents, the value of a formal bug tracking system decreases over time. The volume of bugs that are no longer relevant grows gradually, making it harder to pick out the important ones.
Our current process for handling bugs is lightweight while still ensuring that important and easy bugfixes get delivered. When we encounter a new bug, a quick triage takes place. If the severity is high, it’s fixed as soon as possible. The bug is reported in our flow with a#bug tag and a @mention of the person who has agreed to fix it. Once fixed, the #bug tag is removed. Low severity bugs with trivial fixes are fixed right away, while the rest of them are mentioned in our flow. If a low severity bug starts affecting many of our users, we will see more mentions of it, increasing its severity.
Because the development team handles support, this type of lightweight bug handling is possible. Customer support is an important input when assessing the severity of bugs – important bugs will rear their head via support messages.Handovers Suck
Finally, not having a dedicated support team removes at least one handover. When a support person handles a case by escalating it to a developer or team, they can (correctly) feel that they’ve done their part without actually resolving anything. This is in no way the fault of the support person – they’re acting as they should. But it’s an indicator of a badly designed system.
If you design your customer support system to include handovers – points at which responsibility is absolved – you’re setting users up for disappointment. In addition to delaying resolutions, each handover throws away the rapport that was painstakingly built between a user and a support person.
There are, of course, situations when a handover is necessary. An example is when a team member is unable to fix a reported bug by themselves. We’ve tried tackling this by making the original responder responsible for finding the person to take over the problem – hence the @mention that gets added to the bug report in our flow.Scaling Support Without a Support Team
Since our user base grows at a faster rate than the Flowdock team, this presents a problem: will we be spending too much time handling support at some point? We could hire people to take care of the so-called level 1 support cases.
Unfortunately, this might take away most of the benefits outlined above. Easy support cases are our background hum. They don’t take up a lot of the team’s time and effort, yet provide us with valuable insight into our users: what aspects of Flowdock they love and which features are causing confusion.
We haven’t come up with a silver bullet solution for this challenge. The end result will most likely be some sort of hybrid approach, with the Flowdock team still continuing to handle support. In addition to scaling support, having dedicated level 1 support people does provide a few other benefits: easy issues are handled quickly, on all time zones.
For now, we will continue handling support ourselves while building a user-friendly service that is as bug-free as possible, minimizing tricky support requests. When the scalability of our support becomes an issue and forces us to evolve our process, we’ll be sure to share the outcome on our blog.
Flowdock team members in snowy Helsinki
This post originally appeared at the Flowdock blog.Ville Saarinen