Clayton Lengel-Zigich, Roy van de Water, Derek Neighbors and Jade Meskill discuss why everything that can be automated, should be automated.
Jade Meskill: Hello. Welcome to another episode of the Agile Weekly Podcast. I’m Jade Meskill.
Roy van de Water: I’m Roy van de Water.
Clayton Lengel‑Zigich: I’m Clayton Lengel‑Zigich.
Derek Neighbors: And I’m Derek Neighbors.
Jade: Very nice. Derek, you had something you wanted to talk about. What was it?
Derek: Yeah. I’ve been doing the work with a number of teams, and one thing that I’m starting to see emerge as a pattern is the team’s struggle to go fast. They struggle to work particularly within the Scrum framework a lot of times. Not only are they siloed where they got developers and QA that are separate, but where they don’t have a lot of automation. This could be automation around deployment.
This could be automation around testing, so maybe they don’t have an automated test suite. Or if they’ve got some automated test suite, there’s still some manual regression happening. Even if they have a fully automated suite, they’re not running it automatically.
They’re not having continuous integration, or it takes an enormous amount of long time to build. What I’m finding is it’s very, very hard for them to see what performance looks like, because they can’t get over the concept of their current reality. The current reality is, “Hey, it takes five days to run the test suite. There’s no way we can have a one‑week iteration. That’s just impossible. It takes us one week just to test, once the developer’s done with a feature.”
Have you guys seen instances, where maybe the current reality or the lack of automation makes it so teams just find…I had somebody specifically today, tell me, “That’s really nice that you stand up there and talk about a 10 minute build. Frankly, there’s no way you’ve ever done that before, because I’ve worked for five different companies, and none of them have ever been able to do that. I find what you’re saying impossible to believe.”
Jade: [inaudible 02:06] we have a 10 second build?
Roy: Yeah. I agree. I’ve struggled so hard to get a build to take 10 minutes. I don’t believe it’s possible.
Derek: In their current reality, I understand that. If you’re a manual regression tester, and you’ve got a fairly complicated suite, it’s taking two or three days to run a single test plan. I can understand how it feels impossible that you could, with any level of comfort, run a test suite under 10 minutes that made you feel like you weren’t shipping crap.
Roy: We’re working with the team right now, but we’re not working with working microphones.
Jade: That’s right. We are working with the team right now that a single test takes two weeks of constant computation, a single test.
Clayton: I’ve seen that in a lot of instances where, the technology gets in the way. If you’ve got a job applet that loads a Swf, how do you automate testing of that content? That seems like this impossible thing. I think a lot of people say, “It is what it is, throw my hands up in the air. What else are we going to do but, let those hourly regression people slave away at typing in commands and looking at the screen”?
Roy: Along the idea of trying to test a flash out, I think that’s one of the first mistakes that immediately causes your test suite to get larger, and take longer, regardless of whether it’s manual regression or automated testing. That’s when you write the test case last, after everything is done.
Derek: When you write the test case first, you end up using solutions that are easier to test. You don’t run into those things.
Clayton: That’s one of my favorite things about doing, not even just TDD, but just test first. Where you have to take into account what easy to test and what isn’t. I’m working with a team that has a fairly large fitness test suite. You can, totally, tell the way they went about using fitness to write this acceptance for higher‑level tests, because it was so difficult to test at the unit level, the only thing they could do was test the big black box of spaghetti code. They were all written after the fact.
They were trying to do more of a TDD approach or write unit test. It would’ve been so impossible to write any test whatsoever, if they were actually dedicated to that, they wouldn’t have had to solve that problem in the first place. The reason automation doesn’t get more not popular, it’s because a lot of times team get rewarded for effort. Jade and I were talking about this the other day. If you’re using a lot of effort that probably means you’re dumb. You can be so smart and lazy that you can do a lot of things automatically.
If you work in a system or an environment where you rewarded for staying up till five in the morning working on some stupid thing that should be automated, what incentive do you have to automate things? You’re going to get clapped for, and pat on the back if you put a lot of effort into stupid things. Human nature wise, that seems to make sense. That’s like irrational decision at that point.
Jade: Yup. If you’re putting a lot of effort, it must be important.
Clayton: Yeah. Exactly.
Roy: The part that’s really difficult especially when you go to test after the fact is to justify the expense of writing a test. Because you have this working piece of software that your user could be using right now, why not just release it, and then not worry about the test?
Clayton: I’ve heard regression teams be referred to as backstops and people make a baseball analogy metaphor that’s, “The catcher is supposed to be there to catch the ball and that should be fine, right?”
That’s what I think what the developers think of themselves as, “We’re going to do this thing where we’re going to write something, and I’m going to look at it, and I’m pretty sure it works. That’s kind of the catcher, but in case there’s some wild crazy pitch edge case that gets past me, at least there’s a backstop.”
Pretty soon, they stop trying to catch the ball and everything is just the backstop. I think that’s what happens. Why would you spend the extra time to make sure no bugs or no defects or problems or no nothing ever got to the regression team, because they’re always there?
You know they’re going to be there. If something goes wrong, wouldn’t you rather someone blame them than blame you? That’s always…
Roy: Then you get into that whole QA developer rivalry, too, where you hate them because they’re making you do more work. You don’t get to work on new stuff, because they keep uncovering the crap that you wrote earlier.
Clayton: I really like the way that some people in the QA or testing or whatever community talk about testing versus checking. Those are the things that a computer can do. Making sure that this algorithm works properly in these different cases or whatever.
I really like that idea where testing is more about heuristics and looking at, “How does the system function, and what do I expect to happen? What people perceive and is it consistent with the rest of the thing?”
All the stuff that you, actually, need the human brain for. Those are valuable things that people could be working on, actual people. Everything else really should just be automated. [inaudible 06:56] should be automated checking.
Jade: You posted a really awesome article, I think at the beginning of this week, about a case where a company neglected to use automated deployment. In this case, instead of automated testing, but another case where something is done repetitively and there was an opportunity for automation that wasn’t taken. In this case, I think it ended up costing that company $465 million.
Clayton: Some trading company, right?
Jade: Right. We’ll attach the article to the description, but it was pretty crazy. They break down exactly what happened, and it ends up being, “We just didn’t automate something that should have been automated.” Now it’s human error that comes into play.
Derek: I see some funniness in that one of the things that had come up in some the discussions today, too, was, “Well, one of the things that QA is really incredible for is our business rules are so complex that nobody understands them. Literally, nobody actually understands the business rule.”
The great thing is what we do is we have QA, what would happen is you would basically code the story as a developer, and as you code the story as a developer, my fantastic test plan is going to cover every edge case, so that I can actually tell you how you didn’t understand the business rule.
When I think about that, it sets the fallacy that this stuff is so difficult that we’re going to have humans try to remember how it works. Like, “I’m a human, I know that doesn’t work.”
Clayton: That sounds like the exact opposite of how it should be.
Roy: Right, where if it’s super complicated, and you’ve got this thing, shouldn’t you have the computer be checking that it’s the right thing? Then make it happen faster so that I can get immediate feedback.
That’s what I was kind of saying is, “The problem is that if I go and I code this thing up and it takes me five minutes, and I hand it to you to run your test plan, and it takes you two days to give me feedback, that’s really irritating. What if I could run a 10 minute build and get that feedback immediately, and make an adjustment?
That’s when it just blew up into, “It’s impossible that you could ever have a 10 minute build.” I think the second part I think that the thing was, “Great, if we really automate that stuff, what happens to us as a manual test team? We’re still going to have to do a bunch of stuff.”
I think, if we look at some of the best companies in the world that are really doing continuous deployment well, they’re not having manual testers test. They’re having real users test. When they deploy something, they deploy it to a small set of people or to a small set of systems, run tests on them and continue to get feedback, and continue to let things deploy as they get more and more feedback.
I think in order to be competitive, especially in the kind of high tech space, you’ve got to get to the point where your crap’s automated, man. I just can’t see hanging with the big dogs if you’re sitting out having manual tests. I just don’t think it’s reasonable anymore.
Jade: There’s actually a ton of freedom and liberation in having those things automated, right?
Jade: There’s no need to have human slaves that are doing that. I’ve been reading a lot of Buckminster Fuller, and he talks a lot about freeing the human race from being muscle reflex machines. That’s what computers should do for us. They should free us from having to worry about those types of details, and those repetitive motions that can be fully 100 percent automated.
Roy: Many of those QA people are valuable people that could be contributing so much more than just a menial task…
Jade: Right, than following a script and clicking buttons.
Derek: One of the things I kind of brought up is that in many instances the QA people have the largest amount of domain knowledge in the company. They could be the front and centre of helping to find the product and helping work with customers, because they’re the ones that understand the product most intimately.
Instead of putting them out there helping them make the product better, because of their understanding of the product. Instead we have them doing the menial labor of kind of like sweeping the shop floor every night, which is just ridiculous.
Clayton: I think one thing maybe we’re glassing over a bit is if you already have some big kind of legacy kluge system that it’s not very well tested, maybe has a big manual test sweep. What is the first step in fixing that problem? How do you even start automating things?
Derek: One of things that I’ve been recommending because it’s something that comes up is at the beginning of the sprint the testers don’t have a whole lot to do. QA doesn’t have a lot to do, because there is no code ready for them to test.
Normally what they’ll do is they’ll start to write their test plans. Do the shell of their manual test plans. Then, what happens is at the end of the sprint, the developers don’t have anything to do and this is one of the big complaints about Scrum on teams that work like this is, “Hey, it really sucks, I waste my time because there’s three days left in a two week sprint where I’m not allowed to do anything, because I can’t bring new work in because there will be no time to test it. What do I do with my time?
A lot of times I’ll see Scrum masters say, well what you should do is you should go help the testers by running manual tests. What I’ve been recommending is you should help the testers by helping them automate the tests that they need to be writing, or should be go finding code that is the most complicated code that causes you the most grief. You should be writing tests that surround that code.
In that time that you really can’t go grab new code, because you won’t have time to test it you should be helping the team move towards automation. Starting to create that path and create those good habits, the other thing I intend to say is in a bare minimum start unit testing in all new code you write.
Clayton: Even that’s pretty hard. The one thing I always tell people if they want to go towards automation is it’s probably going to be 10 times harder than you think.
I think for a lot of people it’s kind of like, “OK, we have the manual tests, I can just automate those.” But then you start doing that, if you want to make good choices you end up getting to a point where you really do have to go back and re look at a lot of the stuff.
It takes some skill to be able to go in and look at it, some legacy code base. Legacy [inaudible 13:14] two weeks ago, kind of thing. Be able to go in there and say, “Where can I add some tests?” or “How can I pin this code down, so that I can actually test it and get it under tested, so that I am confident in that test sweep.”
Jade: Yeah, but if you do it for humans, doing testing by clicking around those are some really easy places to start automating. There is lots of great tools out there to automate the clicking around and report exceptions for you.
The last place I was coaching at we ran into this problem where huge legacy system, and I started showing the regression testers how to use Selenium and some tools. There is definitely a lot of challenges in just getting the environment working.
They were able to automate the 80 percent of the everyday stuff, and that freed them up to make much better contributions.
Roy: Yeah, for all the people that have the excuse of our environment is so specific that we can’t really test in an automated fashion. I am willing pretty much to guarantee that there is probably somebody else that ran into the same problem was sick of it, and came up with some way to deal with it.
It may not be pretty. We saw crazy hack together solutions using all sorts of different technologies just trying to get something to work, but it’s still beats having human beings click through that stuff.
Derek: Then I think the second thing is where I see complete lack of automation that causes a lot of team’s pain as round deployment. Whereas, the deployment process is so painful and every time someone deploys they screw something up, and because every time they do something, and they screw it up, a bunch of process comes out about it.
Now you’re not allowed to deploy, you have to fill out a form, and you have to go before a deployment board. Only certain people have access to the production environment. It just cascades into ‑‑ it takes two days to deploy a five minute change. Are you guys seeing stuff like that anywhere?
Clayton: Yeah. I think there’s a lot of rules. I’m getting put around deployment. It’s the same stuff, where you can’t automate it because of some usually like some silly technological problem. People don’t know just how certain things could work or there’s some fear around it where we can’t deploy automatically, because if do that then we won’t get the release notes and user update information out in time.
Like coordinating a bunch of different departments that are all doing things in kind of a dumb way. That you could solve those problems, but people usually just avoid that, like we only deploy every so often so I’d rather just do it manually.
We’d rather pick one poor person that has to stay until nine o’clock to press the button than fix the problem. It’s easier doing that.
Derek: I think maybe some of that in the manual testing as well, is people don’t even know the tools exist. I think that’s part of it. It seems so scary, because I’ve never seen it done before, so I don’t even know that tools exist to help make this stuff easier.
Jade: Yeah. It does look like magic, if you’ve never seen it before.
Clayton: If you’re a windows developer.
Jade: On that note that’s all the time we’ve got for today. Thanks for listening to our weekly podcast.
Often in agile we are so focussed on improving and finding the next impediment to solve that we forget how far we have come. Most importantly we forget to celebrate the small victories we achieve each day.
Recently we had a skype chat with agilesensei and he mentioned a great technique he uses on nearly all his kanban boards. It’s a Ready to celebrate column. It comes just before done, but it’s an important extra step because the whole team take a short moment to acknowledge and celebrate what they have achieved.
I often see new teams naturally do this, because the idea of finishing a small concrete piece of work is astonishing compared to how they have worked in the past. But somewhere along the line it becomes the norm and we stop recognising the amazing work we are doing. If that’s true then add a ‘Ready to celebrate‘ column to your board, and celebrate each time a story is done. It doesn’t have to be huge, just a cheer at standup works well.
We tried it out recently on our video project. After each video was complete the whole team high fived and cheered. It seems silly. But it was great fun, we felt a sense of achievement and it provided a great way for the whole team to know exactly how far we were from our goal.
Last month we released a new Snippets tool that allows you to easily create syntax highlighted code snippets to share with team members. While the tool has been widely accepted, many users asked for the ability to insert these code snippets inline with wiki pages, tickets, messages, etc. We listened and just released this updated functionality. Here is how it works:
Create the snippet and copy the markup reference (see below).
Paste the markup reference into any wiki page, ticket description, ticket comment, merge request comment, message, etc.
Save and your snippet will now show inline. Any changes to the main snippet will reflect wher ever it is embedded.
If you do not have the Snippets tool installed, check out the release announcement for instructions on how to install it.
We hope you enjoy this new feature. Happy coding!
As more and more people are discovering, visual management is a good thing. When you can actually see what you’re working on it’s so much easier to: Understand what you need to do Identify and fix problems Get things done faster At LeanKit, we’re discovering first-hand the diverse and creative ways people are using visual [...]
Practical Systems Thinking: Exploiting the Constraint
In our second video of the series from last week, “Identifying the Constraint” we covered how you go about identifying the constraint(s) in your system, using an agile task board or a Kanban board. Because when it comes to system constraints, we know there’s always at least one.
So now that you know how to pinpoint the constraint within your Kanban or Scrum system, you can work on breaking that constraint. Step number two in the “Five Focusing Steps” of the Theory of Constraints shows you how to break the constraint by first exploiting it.
In this third video of our series focused on Systems Thinking, I will explain what it means to “exploit the constraint”. Exploiting the constraint doesn’t mean having your constraint work overtime! We are not taking advantage of people, we just want to keep the constraint busy and not have to wait for work and focus the work of the constraint on its unique capability. We’ll also show you how to keep the constraint busy by creating an even and balanced flow of work through it.
Practical Systems Thinking Part 3: Exploit the Constraint
Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.
The post Practical Systems Thinking: Exploit the Constraint appeared first on BigVisible Solutions.
A team that I have coached took up and voluntarily committed to a sprint backlog that was not realistic. Worse, not only it was clear afterwards that it was unrealistic, but they knew already right from the start of the sprint. How come they committed to a sprint backlog while they already knew it was not realistic?
This team started their first sprint while work on the product backlog was still work in progress. They took up a few user stories that were already ready. With only a few user stories ready on the product backlog, estimating story points does not make much sense. Since it is a relative measure one needs more than a few user stories to start estimating story points. In 1 or 2 sprints we’ll have enough user stories to estimate in story points and measure velocity.
One could choose not to start with scrum when not enough stories are on the product backlog. In this case there was momentum in the organisation and team to start with scrum and we chose not to postpone but to start.
In the second sprint the team committed to a sprint backlog while in their minds they did not want to commit. Of course, not having a velocity did not help. Blaming it all on the lack of having a velocity measurement is too simple. There is more.Velocity
Velocity is defined as the total amount of work measured in Story Points that the team delivered in the last sprint. There are some subtleties, e.g. when the team has unfinished user stories.
Its main use [ScrumGuide] is two-fold. First, the team uses the last achieved velocity as a measure for the amount of work that they will take up in the next sprint. Second, it is used as an insight to the product owner to help in forecasting what features will be finished at a given date. This helps the product owner in prioritising the backlog.
Note: The scrum guide does not explicitly mention velocity. Rather it mentions the ‘team’s past performance’ and that the product owner ‘assesses the progress towards a goal’. In practice many teams use ‘velocity’ for this.Planning Meeting
In a scrum planning meeting the sprint backlog is established. With teams I help them build up the sprint backlog by starting with the most important user story and let the product owner explain the story. The team gets to ask questions to clarify the story. Finally, I ask the team whether they can commit to completing this user story for this sprint. If ‘Yes!’ this procedure is repeated for the next user stories until the team will not commit anymore. The limit for this sprint has been reached. The velocity helps as a check that the current sprint backlog is realistic. This is based on the team's result form the past.Group Conformity
There is another important use for the team’s velocity. Not only does it help the team in determining how much work they can finish in the next sprint, but it also guards against the group conforming to committing to a sprint backlog when in fact some or all team members think ‘No!’.
This phenomenon is known as ‘Group Conformity’ and was demonstrated in the ‘50s in a series of experiments known as the ‘Asch Experiments’ [BlogChe].
These experiments showed that in a group members tend to conform to the opinion/believes of the group even if they think differently. Instead of going against the group members conform to the group’s answer. E.g. in order to avoid being ridiculed.Planning Meeting...Again
Back to the team. What happened in the planning meeting?
In the planning as a coach I ask the commitment question after adding each user story. The questions are asked to the team one team member at a time. The first few said ‘Yes!’. Finally all team members said ‘Yes!’. But were they also thinking ‘Yes!’? Probably not.
What could be the reason for thinking ‘No!’ and saying ‘Yes!’? Inspired by a colleague [Gro13] I can think of:
- after having discussed the user story with the product owner for 10 min. it may be difficult to say ‘No!’, because this indicates that just 10 min. of group time have been wasted; conforming to the group and saying ‘Yes!’ is easier,
- after a few have said ‘Yes!’ it becomes increasingly less easy to say ‘Yes!’, again conforming to the group is easier,
- for the last members to be asked a ‘No!’ sounds like a ‘veto’ which doesn’t feel nice and (again) conforming to the group is easier.
Using the velocity as a tool to decide that the sprint backlog is full and no more user stories should be taken prevents the line of thinking shown above. Team members do not have to say 'No!', their proven past performance does.Role of the Scrum Master
How could you help as a scrum master?
Stick to the process and use the velocity to guard against group conforming effects. The velocity will tell the group that the limit of what is realistic to pick up in the next sprint has been reached, thereby preventing that the team thinks ‘No!’ but says ‘Yes!’.
This will help the team only on the short-term.Role of the Coach
What is the role of the coach?
The team coach should stimulate the exchange of ideas and especially the differences in opinions between team members. This will help team members not to conform to the group.
Conforming to the group you would expect to see particularly in groups that have just formed. Here members in the group are reluctant in stating ideas and opinions that are different from the rest of the group. The role of the team coach would be help the team through this fase in group development.
This approach will help the team on the long-term.Conclusion
Besides helping the team to determine the size of the sprint backlog and helping the product owner to prioritise, use of velocity aids the team to prevent committing to a sprint backlog while they actually do not want to commit.References [ScrumGuide] Scrum Guide, Ken Schwaber, Jeff Sutherland, 2013, https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide.pdf#zoom=100 [BlogChe] The Asch Conformity Experiments, Kendra Cherry, http://psychology.about.com/od/classicpsychologystudies/p/conformity.htm [Gro13] Group Conformity, Rik de Groot, October 2013, Xebia XKE TED style
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
It’s excruciatingly boring to write specifications. It seems like it’s the most boring thing in the world that a product owner has to do. This could be the reason why most specifications are horrible and come across as the root cause of delays, reworks, and bugs.
This problem can be partly alleviated if a product owner is always available to talk to, but even that is not a cure-it-all remedy.
The agile movement has its peculiar point of view on specifications. The most extreme part of agilists express their feelings quite clearly:
F%$k the specifications!
But someone actually asked this question this week, adding presumably to avoid embarrassment that the purpose was to "translate reality into management artifacts". He has a point of course. Familiar artifacts can allow people to see new things more clearly; we just also need to ensure that we've all understood what is really different in the new world.
Any way, I suggested looking at the Open Source tool xProcess, which uses its built-in forecasting engine to put start and end dates on a hierarchical collection of tasks or work items based on size estimates and team availability. I reckon if you have a table with task names you can generate such a chart in about 5 minutes.
Here are the instructions. Download xProcess from this site: http://sourceforge.net/projects/xprocess/
1. Create a project by hitting the "New" button like this:
You can choose various templates but just choose Simple Process / Simple Project. It's the.. well simplest.
2. Add the list of work items by selecting "New" again and "Task". (See next screenshot).
3. Hit "Next" and you can add all the names from the cards on your wall as a comma separated list (see screenshot on the right). Leave the "Size" as 2 - we'll come back to that.
4. Now when you go to the Task List tab (or hit the "Tasks" button) you should see something like the screenshot below. All your tasks are listed all of size 2.0 and with start and end forecast dates of NEVER.
In other word the Scheduler is forecasting none of these task will finish. That's because we have no resources assigned to the project. The simplest quick fix for this is to add yourself to the project. So...
5. Hit the "Resources" button and then "Add/New Resource", select yourself (or add team members) and then hit "Next". This gets to the "Appointment to Project" dialog shown below. You can define availability on this screen or just hit "Finish".
We now have enough information to generate a Gantt chart, albeit with some fairly big assumptions such as a uniform size of tasks and 100% availability of the team we've assigned. Nevertheless we can hit the "Gantt Chart" button and see the result.
Here's my attempt.
There are lots of things you may wish to adjust at this point like the priority order of the tasks, the estimates for the items (either the default value or individual ones) and team availability. You can even add separate subtasks for different parts of the process into a task template and add team roles so the right people are assigned to the right types of subtask. There are lots of adjustments you can make depending how much longer than 5 minutes you want to spend on this. You can even enter (or generate) fixed "target" dates which compare the forecast dates with dates that may have been agreed with a customer ( or are simply the forecast from last month). Endless hours of fun are possible. :-)
However if you just want to give your manager a comforting diagram, the steps above could be 5 minutes well spent!
File this under, “Getting Started with Visual Management.” I was at a customer site the other day as they had expressed interest in learning more about the metrics and reporting capabilities available in LeanKit. As we were looking at their board I was struck by the sheer number of cards showing work in progress. Many [...]
Airbrake.io recently released an integration that will automatically creates Assembla tickets for errors detected via Airbrake’s monitoring and reporting. With this integration, your team can quickly begin correcting issues while documenting the progress and status in an Assembla ticket.
To learn how to connect your Airbrake account with an Assembla project’s ticket tool, check out the documentation here.
If you are not familiar with Airbrake, they are one of the leading exception reporting services available for tracking application errors. Their reports tell you what errors are happening, what bit of code are responsible, and allow you to recreate the error for rapid debugging. At Assembla, we use and love Airbrake!
Back in May, Assembla and Airbrake put on a joint webinar on “Production Monitoring: The Key Steps Towards Continuous Delivery.” To learn more on how and why Production Monitoring is the most important process in any application, but particularly online applications when practicing Continuous Delivery, check out the recorded webinar.
Do you know where the constraint is within your system? Are you aware that you have one?
Our first video in Practical Systems Thinking talked about having an appreciation of your system. All systems have constraints – including software development systems. Whether you are doing Scrum, Kanban or waterfall, there will always be a constraint. It’s the constraint within your system that determines your system’s throughput. Therefore, optimizing anything else other than your constraint will not increase your throughput.
So where is the constraint within your system? Are you actively working at breaking that constraint? Or are you unaware that you might be focused on improving non-constraint components in your system that will not increase but decrease your throughput?
In this video I introduce the “Five Focusing Steps” of the Theory of Constraints for breaking the constraint within a system. The first step is being able to identify where it is in your system.
I’ll show you how an agile task board can be used to identify the constraint within your system. I’ll also show you that just relying on burn down charts is not enough for effectively managing the work in your sprint.After you have identified the constraint in your system, you can then go about breaking that constraint.
Next week’s installment: Exploiting the Constraint. We will talk about step #2 in the “Five Focusing Steps” for breaking the constraint in your system.
Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.
The post Practical Systems Thinking: Identify the Constraint appeared first on BigVisible Solutions.
Well really that is three questions. Firstly what is a kanban?
1. A kanban is a visual signal.
It is a Japanese term meaning a card, brand or sign. In lean production systems it's used as the signal to an upstream part of the process that items are required by a downstream part of the process.
Which leads to the next question. What is a kanban system?
2. A kanban system is a system for managing work that uses (real or virtual) kanbans to control the flow.
Kanban systems were first used in Toyota for manufacturing but are now widely used in a wide variety of applications including health services and knowledge-based work such as software development. In principle a kanban system is a "pull-system" where work is triggered by demand from a downstream part of the process - ultimately by the demand of the consumer or commissioner of the product. The systems use kanban signals to prevent over or under production in various parts of the process. The kanbans may be "real", for example an empty hopper which is sent back on the production line to indicate that more parts of a given type are needed, or "virtual", such as the signals derived from a kanban board when a "story card" is moved out of a column. In both cases they indicate to the upstream process that another item should be produced, processed or selected.
"But hang on! I thought Kanban was a method."
You're right. That's the third question, the third part of what is Kanban. To be crystal clear, we should ask "What is the Kanban Method?"
3. The Kanban Method is an approach to defining and improving kanban systems.
The Kanban Method emerged from work being done by many practitioners in software management, agile and lean methods and new product development during the first decade of this century. The author of the method was David Anderson, but many others contributed or were doing similar work which fed into the method, including Drago Dumitriu, Jim Benson (co-author of Personal Kanban), Don Reinertsen (author of Flow), Karl Scotland, Corey Ladas (author of Scrumban), Alan Shalloway, Arne Rooke, Mattias Skarin... there are many more than I know about. Kanban was first formulated as a method in a paper presented by Anderson at the Agile 2007 conference in Washington DC, and in 2010 Anderson published what is still the principal authoritative text on the method, "Kanban: Successful evolutionary change for your technology business".
As Alistair Cockburn has observed the word "method" may confuse here - he suggests "reflective improvement framework" is closer to the intention (if it weren't such a mouthful I might agree with him!). I would say Kanban is a method, but a method for defining and improving a process, not the process itself or even a process framework. As such people are often confused by what they think are properties of the Kanban Method, whereas in fact they are simply characteristics of a particular kanban system that they have observed. Try not to be confused or you may miss the crucial value that Kanban can bring to your organisation - continuous evolutionary improvement. A method such as Scrumban for example is an application of the Kanban method to a process that starts off as Scrum or Scrum-like. Scrumban is Kanban, but in a particular context!
Elsewhere in this blog I discussed my shortest possible guide to adopting Kanban, based on the underlying paradigm, the principles and the practices of the Kanban Method. Here it is again:
I’ve been thinking about metrics recently. Most people who use Scrum understand velocity. It’s pretty simple. How many points do you complete each sprint on average? As teams move towards more continuous flow approaches, like Kanban, somehow the metrics seem to get lost. It’s pretty simple to calculate cycle time. Write the start date/time on a ticket when it enters the system and write the end date/time on the ticket when it’s done. Calculate how long each ticket took. Average it to get the average cycle time.
However the really interesting idea to me comes from Lean, and that’s the idea of Takt time. It’s not quite the same as cycle time. This great post explains the difference. What I love about Takt time is that it is related to customer demand.
Basically Takt time tells us how fast we have to work to keep up with customer demand. What’s great about this is that there is no point in working faster than takt time. You will just create an inventory build up which is waste (muda). My favourite story on this comes from Lean Thinking. They explain how a factory had a really expensive machine to spray paint bicycle frames in seconds, however when they worked out their takt time they realised they didn’t need the machine to be that fast. They bought a much cheaper machine that was slower without any impact to productivity.
To help understand some of these metrics I took a video at a breakfast stall at our local saturday market. The stall is no regular stall, it’s Luke Dale-Robert’s breakfast rostis. Luke is one of South Africa’s top chefs and a lean machine! Watch the video below and see just how lean his setup is. Once you’ve watched it I’ll walk you through the calc for cycle and takt time.
If you watch the video with the stopwatch like I did, here’s what you will notice. The process starts with putting some potato mix from the plastic tub into the first frying pan. Once that’d ready the pans get switched: 1 moves to 3, 3 moves to 2, 2 moves to 1. The rosti in pan 2 gets flipped, and the rosti now in pan 1 then gets plated, and the process starts over. It takes 3 minutes to create the rosti.
At around 3 minutes I have moved around the stall to the plating section. Here you can see that once a rosti is plated it gets bacon, a poached egg, grated cheese, hollandaise sauce and some chives, and it is then served. It takes 36 seconds to plate the food and serve it.
So the cycle time for one plate of Luke’s breakfast is about 3 min 36 secs.
I started the video when I joined the queue, and the video is 4 min 30 secs long. In that time 9 people were served (including me – that’s my rosti at the end – YUM!)
So Takt time for the time I was there = 4 min 30 sec / 9 = 30 seconds.
i.e. The stall has to produce a rosti every 30 seconds to keep the queue moving and people like me happy.
How does he do it? Well what you can’t see is that there are actually 6 pans cooking rosti’s. There is a second station to the side. Since this is the most time consuming part, Luke has doubled the capacity of this station since otherwise it would be the bottleneck. 3 minutes per rosti, and 6 rosti stations means a rosti is produced every 30 seconds, exactly the required takt time. No more no less. I told you he was a lean machine!
What I know from coming here alot is that the queue is pretty consistent from 9am to 12pm (when they run out of potatoes). At 1 plate every 30 seconds and R50 a plate. I estimate they are making R18,000. Work out food and staff costs and this would be a pretty simple calculation for profitability.
If his breakfast wasn’t that popular he could double his takt time to 1 min and reduce his costs by getting rid of the second rosti cook. Note the cycle time for a rosti would still be the same. This is why takt time is a much more interesting metric for me, because it takes demand into account.
So now think about your team? What is your cycle time? What is your takt time? Do you need to go faster or slower to meet customer demands? Where is your bottleneck? Would doubling capacity in one place halve your takt time? What is the impact on profitability?
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Wow, what a learning experience AgileZen 2.0 Beta has been. We learned a lot about real-time communication, an easy to manage backlog, and building an iPad application. We also had the opportunity to get in-the-moment feedback from our users, many of them outside of Development and IT and instead in Marketing, Recruiting, Sales and the like. We appreciate all of the emails, tweets, feedback, and forum entries letting us know how we can improve your project management experience. More than that, we want to say thank you for being such great customers and helping us build, iterate, and learn with you.
Here comes the tough part… We’ve decided to fully support the Original AgileZen, and stop development on AgileZen 2.0 Beta. We will be refocusing, taking some of the awesome things we’ve learned and bringing them into the Original AgileZen. And, since our teams reform every now and then at Rally, some of us will rotate in and out of other product teams.
What does this mean for you? We’re here to help you extract your data and get it back into the Original AgileZen. You’ll need to do this within the next 90 days because at that time you won’t be able to log into Beta any longer, and all data will be removed from it. You won’t be able to log into AgileZen Beta after 1/14/2014 so contact us at firstname.lastname@example.org and we’ll help you get your projects ported over. You can also use the public API to do it yourself.
What is your real objective? To plan for maintenance hours or to ensure that your team is optimally utilized working on both user stories and defects while turning out quality code on a continuous basis, including defect fixes?
We have received a few comments from customers that Filters are hard to use. We have changed the Filter’s menu so it requires less clicks to get to your data.
In this guest blog post, Agile evangelist and AgileZen user Rebecca River Forbes suggests the idea of running your family life in an agile fashion. Rebecca gives insight into how agile methodology can reach beyond software and into every day life. She uses AgileZen to help her work through life in an agile way.
Poor management of your family life can be making your children miserable. Bruce Feiler begins his talk Agile programming – for your family (TEDSalon NY2013) with a study showing that the number one wish children have for their parents is for them to be less tired and less stressed.
Feiler is using methodologies designed for managing software development to manage his family life more effectively and everyone is happier and more relaxed. These methodologies are called ‘agile methodologies’ and the principles can be applied to almost any kind of project or activity, including your family’s daily routines.
What is ‘agile’?
Agile methodologies started as ways to manage software development. Since its conception, word of agile spread, and its principles are being applied to all sorts of projects. I’ve used Agile to manage my workload when I’ve had lots of different projects running at the same time, each project involving different people and with its own series of deadlines. I use it for writing fiction, to keep track of the story lines and the characters’ timelines, and I’ve taught it to people faced with the daunting task of setting up a complex business from scratch.
Agile principles are easy to understand and implement in many situations where you need to manage a project as a group or on your own. In ‘Agile programming – for your family,’ Felier uses agile methodology to make family life more organised and less stressful.
In 1983, Jeff Sutherland, a technologist, noticed that 83% of projects failed because information percolates down to programmers, Instead of the programmers being consulted. Sutherland set about designing a more agile method of working, where information flowed more freely and people were consulted on the work they would be doing.
Agile is a reaction to the classic waterfall method of project management, which you’re probably more familiar with even if you don’t work in software development. In a waterfall project the person at the top gives the orders to the people at the bottom. In the same way, an authoritarian parent will use the ‘what I say goes’ approach and there’s little room for negotiation or input.
In an agile project the emphasis is on collaboration and communication. I see agile as a more humanistic and holistic approach to achieving a common goal. It is collaborative rather than authoritarian, communicative rather than dictatorial. Each member has input into what the tasks are and everyone is able to put forward ideas. In software development, the designers often have ideas about how something could work, so they should be able to make suggestions to the developers. In return, the developers may have good ideas about how something could be designed. We are not single-use mechanisms, with no knowledge of any other role other than our own. When working as a team, many brains are better than one.
Why should you care about agile if you’re not a project manager?
You’re not a project manager – really? Every day we don our project manager hat as we try to schedule things into our daily routines. We manage our social lives around our jobs; we plan holidays, celebrations and events; we organise our family life. Most of us are busy floundering in chaos trying to manage several projects at once. The beauty of each ‘project’ is that no matter how big or small, it can usually be broken up into smaller tasks, and agile is a very useful methodology for keeping track of and completing these tasks calmly and efficiently.
How you can benefit from adopting the key principles of agile
1. Break large tasks into smaller, more easily digestible chunks. This way the task is less daunting and there is no chaotic multi-tasking in which you’re working very hard but nothing seems to get finished.
You work on one small task at a time. If that task is blocked – for example, if you’re supposed to wash the car, but your sister has borrowed it that day – you can just leave that task on the board, and choose another task to do instead. When you’ve finished the task you’re working on, you then look at the board and the blocked task is still there. Maybe you could work on it now? If it’s still blocked then pick up the next fresh task.
2. Collaboration and cooperation. The people involved collaborate and agree on the solution, then they take responsibility for their parts in it. Studies show that when people are given a personal stake in what’s going on, if they feel in control, rather than dictated to, motivation and achievement will follow (1). Felier asks us to empower our children, to give them a say in rewards and punishment, to let them succeed and fail on their own terms. Allow them the space to take control of their own lives.This could be a practical problem, like how the washing up is divided fairly, or a discipline issue, like what to do if someone is overreacting to a situation, as well as how much leeway they should be given and what happens if it goes past the leeway.
3. Communication. Agile encourages responding to change rather than following a fixed plan. Hold short daily meetings, not going over ten minutes, where each person says what they’re going to do today and what they did yesterday.
4. Adaptability. This brings to mind the famous Rita Mae Brown quote, “Insanity is doing the same thing over and over again but expecting different results.”
Bruce Feiler applies this to rule-making when he says, “Unless you’ve anticipated every problem at the beginning, then you don’t have the right rules.” So build adaptability into the meetings. Members can discuss what went well and what went badly for them this week. If something goes well, it can be repeated. If something is going badly, have a separate discussion to see how things could be done differently.
Feiler’s wife began to love and treasure these daily meetings. Parents feel more involved in the lives of their children and are able to respond if they feel something is going wrong.
5. Build your bedrock. A sense of belonging to something bigger than yourself builds self-esteem and commitment to the family.
Businesses start with core values and a mission statement. They want you to be proud of belonging. This is important in families too. You have a shared history and a story. Researchers at Emery asked children questions to see if they knew their family history and key family stories, like the story of a family member who has overcome a problem. They found that the children who knew their families’ stories had the highest self-esteem. So build your core, make your family a cohesive unit in which every member feels a deep sense of belonging and commitment. Make sure they feel valued and empowered by communicating with them and involve them in decision-making.
How to Get Started
Watch this talk in full on TED.com and see how agile programming worked for Bruce Feiler’s family: Bruce Feiler: Agile programming for your family
AgileZen is a free agile management web-based tool that I’ve been using for years. You don’t need software if you want to use agile methodologies, you can implement as much or as little as you like. You could just apply some of the principles above, or if you’re going to use a board, it’s often done with a white board and post-it notes. When I need to keep it digital, AgileZen is very simple to use and effective.
(1) Journal of Educational Psychology Copyright 1990 by the American Psychological Association, Inc. 1990, Vol. 82, No. 1, 22-32 0022-0663/90/$00.75. ‘What It Takes to Do Well in School and Whether I’ve Got It: A Process Model of Perceived Control and Children’s Engagement and Achievement in School.’ Ellen A. Skinner, James G. Wellborn, and James P. Connell.