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
As I write the program management book, I am struck by how difficult it is to estimate large chunks of work.
What can you do? Here are some options:
- Plan to replan. Decide how much to invest in the project or program for now. See (as in demo) the project/program progress. Decide how much longer you want to invest in the project or program.
- Work to a target date. A target date works best if you work iteratively and incrementally. If you have internal releases often, you can see project/program progress and replan. (If you use a waterfall approach, you are not likely to meet the target with all the features you want and defects you don’t want. If you work iteratively and incrementally, you refine the plan as you approach the target. Notice I said refine the plan, not the estimate.
- Provide a 3-point estimate: possible, likely, and worst case. This is PERT estimation.
- Provide a percentage confidence with your estimate. You think you can release near a certain date. What is your percentage confidence in that date? This works best with replanning, so you can update your percentage confidence.
Each of these shows your estimation audience you have uncertainty. The larger the project or program, the more you want to show uncertainty.
If you are agile, you may not need to estimate at all. I have managed many projects and programs over the years. No one asked me for a cost or schedule estimate. I received targets. Sometimes, those targets were so optimistic, I had to do a gross estimate to explain why we could not meet that date.
However, I am not convinced anything more than a gross estimate is useful. I am convinced an agile roadmap, building incrementally, seeing progress, and deciding what to do next are good ideas.
With internal releases, everyone can see the project or program progress.
In addition, we have a quarterly external release. Now, your project or program might not be able to release to your customers every quarter. But, that should be a business decision, not a decision you make because you can’t release. If you are not agile, you might not be able to meet a quarterly release. But, I’m assuming you are agile.
You might need to replace MVPs with MIFS, Minimum Indispensable Feature Sets, especially at the beginning.
If you always make stories so small that you can count them, instead of estimate them, you will be close. You won’t spend time estimating instead of developing product, especially at the beginning.
You know the least about the risks and gotchas at the beginning of a project or program. You might not even know much about your MIFS or MVPs. However, if you can release something for customer consumption, you can get the feedback you need.
Feedback is what will tell you:
- Are these stories too big to count? If so, any estimate you create will be wrong.
- Are we delivering useful work? If so, the organization will continue to invest.
- Are we working on the most valuable work, right now? What is valuable will change during the project/program. Sometimes, you realize this feature (set) is less useful than another. Sometimes you realize you’re done.
- Are we ready to stop? If we met the release criteria early, that’s great. If we are not ready to release, what more do we have to do?
Here’s my experience with estimation. If you provide an estimate, managers won’t believe you. They pressure you to “do more with less,” or some such nonsense. They say things such as, “If we cut out testing, you can go faster, right?” (The answer to that question is, “NO. The less technical debt we have or create, the faster we can go.”)
However, you do need the planning of roadmaps and backlogs. If you don’t have a roadmap that shows people something like what they can expect when, they think you’re faking. You need to replan the roadmap, because what the teams deliver won’t be everything the product owner wanted. That’s okay. Getting feedback about what the teams can do early is great.
There are two questions you want to ask people who ask for estimates:
- How much would you like to invest in this project/program before we stop?
- How valuable is this project/program to you?
If you work on the most valuable project/program, why are you estimating it? You need to understand how much the organization wants to invest before you stop. If you’re not working on the most valuable project/program, you still want to know how much the organization wants to invest. Or, you need a target date. With a target date, you can release parts iteratively and incrementally until you meet the target.
This is risk management for estimation and replanning. Yes, I am a fan of #noestimates, because the smaller we make the chunks, the easier it is to see what to plan and replan.
We need planning and replanning. I am not convinced we need detailed estimation if we use iterative and incremental approaches.
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]