by Phillip Cave
This final post in the series (see Part 1 and Part 2) examines failure, mistakes, destruction, and ghosts. Since I wrote this around All Hallows Eve time, it seemed appropriate. I am fascinated at what we choose to fear and hide or how we deflect from the core problems or blame. Thinking of my career, I make the most progress with personal and professional growth in environments where I am allowed to experiment, hold discourse, disagree, and derive a solution instead of living in fear of “getting it wrong”. Leadership’s responsibility is creating environments of trust and safety, improving the delivery process by listening to their teams, and implementing ideas. Read on.
10. Failure counts as done. So do mistakes.
Getting done means we learned something. Something either worked, or did not work, or worked in a way we didn’t expect. Failure means we can now move on to the next thing, which will either work or not work. (See Scott Adams' Secret of Success: Failure.) It is OK to fail as long as we learn from it — that we learn what not to do as well as what to do.
A saying I like from my time in lean operations at a health insurance company is “fail forward fast”. It means that sometimes failure happens and it is just fine, and it is better to find out sooner rather than later. This is because it helps us get to the done we want to arrive at. Riddle me this … if you are going to fail (and you sometimes will), would you rather fail quickly or slowly? Me, I want to do so quickly and learn what works. In general we have this fear of failure. I believe this is because we may have been victim to management that punished failure instead of fostering an environment of learning. This leads to dysfunctional political posturing, CYA actions, and a legalistic “document everything up front” behavior in the belief this will mitigate failure. Here is a thought … what if we embraced learning and mitigating failure by finding mistakes quickly. This is just one of management’s responsibilities in a lean culture: Create a learning environment and help teams find and correct mistakes quickly.
11. Destruction is a variant of done.
Some things should be destroyed, like old dilapidated buildings and zombies, and old crappy code … and zombies (cuz they just keep coming at you). Think of the mythical phoenix. Its destruction makes room for the next iteration or version. If you don’t need it, destroying it creates less complexity. If you need to improve it, start killing it off and replacing it with the next version. It’s ok to let go of bad investments and code that just is not allowing us to get stuff done as effectively as we want to.
12. If you have an idea and publish it on the Internet, it counts as a ghost of done.
But ghosts have no real substance. This is exactly like a ginormous requirements document — it has no substance and it is a ghost of done. Done is taking what you wrote about in the requirements document and actually giving it life. Done = Life, and ain’t life grand?!
Alternatively, if someone picks up your idea that you published on the Web and then creates something (like the thought leader behind Tesla, Elon Musk, publishing his short and succinct idea for a high-speed train called the Hyperloop), then you contributed to done, but you didn’t get it done. Since an idea is a ghost of done, why spend a lot of time trying to communicate it in a ginormous document when you can write it down as a placeholder, in a short sentence or two, which elicits real conversation that can lead to done?
13. Done is the engine of more.
<this space left intentionally blank> … well, with the exception of actually containing the words “this space left intentionally blank” because then it is not really blank, is it?! You are now done with your choice to read this blog, now go get other stuff done. And may the force of done be with you … gesundheit!
Or – why you don't need to hire heroes
by Ron Quartel
Before I start, please understand that I am not trying to belittle anyone here, or infer that they are a second- or third-rate developer. I personally could not make it through the Google interview process, so include me in the category of “developers that Google rejects”. (Though I'm pretty sure I could have gotten through the interviews when fresh out of college, when all the math and computer science algorithms were fresh in my head. With that in mind, I find it no surprise that 98% of the company are under 30!)
The Software Giants have hired all of the top-shelf developers
“We can only hire middle- to low-end developers here at our company. Google, Microsoft, and Amazon pay more than we can, leaving the market with only second- and third-rate developers. Even if we had the money, there aren't any first-rate developers around, because these software giants have sucked them up from the development pool.” This is a rough quote I heard from someone working at a software firm in the Pacific Northwest. His perception was that the quality of developers and development has been steadily falling at his company during his tenure. The firm used to be able to attract high-level talent, but found that it now was unable to match the salaries and packages of its very wealthy software giant neighbors. I assured him that all was not lost and, in fact, the firm is in a better position than he thinks! Read on.
Teams can do things that geniuses can’t
The collective capability of a team is larger than that of a genius. Agile development is based on self-organized and self-managed teams. The synergy of a team’s collective mind and skills will give you the same, if not better, results than the genius approach, along with some other added benefits. These include:
You don't have the “win the lottery” or “hit by a bus” scenarios to worry about
Knowledge is spread among the team, so vacation time doesn’t affect your project plan
It is cheaper (as you are able to hire juniors and the middle-shelf developers)
You’re less likely to have to deal with large egos (that you often find with elite devs)
Working with a team is fun
Recruitment is easier (as you have a larger pool to pick from)
Teams come up with more options when problem-solving, since there are many points of view
Creating a team
Are you sold? If so, you will need more than just lumping a group of devs under one project and calling them a team. That is a group, not a team. The real magic happens when this group of devs have had time to gel together and go through the forming, storming, and norming phases to become a team. To foster this, I recommend co-locating the team in a collaborative (open space) environment, preferably near the customer they will be working for. This team will come up with creative solutions above and beyond what a single genius developer could. OK, now we have the start of a team. Next is a process to ensure that the same results (complex algorithms) can be achieved.
A software process that will get you to the same point as the genius
Enter Extreme Programming (XP). The processes of simple design, TDD, and merciless refactoring will return the matching results that a genius would. These practices are a repeatable and reliable way of producing code of high quality and complexity.
The genius interview process usually entails complex questions or scenarios that require a very clever algorithm to solve, and the test is to see if you can come up with the correct algorithms and approaches that they have in mind. If you were to create a set of acceptance criteria and tests that would determine whether the result met your requirements, I can pretty much guarantee you that I can solve the problem — particularly once I understand what you are trying to achieve, so I can iterate from simple through complex and get feedback throughout. And that, my friends, is XP in a nutshell.
The Extra Perks
There are more perks that come with XP and with an Agile team approach:
Individuals can come and go from the team throughout the process, and progress carries on regardless (though you want to minimize team changes — team persistence, pair programming, collective code ownership)
The code is easy to read/maintain and quick to debug (collective code ownership, coding standards)
You will not be accruing technical debt, which would ultimately result in a legacy system (merciless refactoring, sustainable pace, automated testing)
Minimal to no documentation is required (code as documentation, tests as documentation, refactoring tests)
New and junior developers have a very short lead time to reach full productivity when joining an XP team (simple design, pair programming)
A persistent cross-functional Agile team practicing XP will deliver high-quality results more quickly and at a lower cost than relying only on top-shelf developers.
by Bryan Stallings
The ScrumMaster has to be a true team member without seniority — there should be no titles within the team.
by Dan Williams
Compliance means different things to different people. As I am using the term, compliance is about proving to someone – often an auditor, whether internal or external – that a company is following the processes and procedures that it says it does. These processes are most often put in place to support regulations that constrain the industry segment in which the company operates. In this post, I want to suggest some ways in which Agile methods and perspectives address compliance.
Scrum, a light-weight Agile project management framework, promotes transparency, reporting, and risk mitigation through short iteration delivery of value. Extreme Programing (XP) promotes automated testing, continuous integration, and close-client involvement. By combining these Agile frameworks, "compliance” becomes part of an Agile culture of value delivery.
The following bullets outline an approach to an “Agile Compliance Culture”:
- Identified Compliance Control Objectives become part of the Product Backlog as User Story Acceptance Criteria.
- Control Activities, which are derived from Control Objectives, are automated in testing when possible. An example would be automated logging.
- Automated test suites are run continuously, providing a compliance health check, thus reducing risk.
- Compliance is built up iteratively rather than in a big bang fashion, thus reducing cost.
- Compliance becomes part of the Agile delivery culture.
Compliance is not optional, nor an add-on to standard software development and delivery. Agile values of transparency, risk mitigation, reporting, high customer involvement, and continuous testing readily support a highly-valued compliance software delivery culture.
by Bryan Stallings
Scrum by definition states that there should be one product owner who sets priorities for the team. What do you do when many influencers on your team want to play this role?
by Phillip Cave
The first post in this three-part series began by stating my thoughts on the principles behind getting done. If we think about how we deliver value and what customers of our products care about, we have to wonder what our customers would say if they could observe our day-to-day activity. Would they be happy with our progress and the activity we choose to do in order to get done? This second post in the series picks up where I left off and dives right in to more principles to ponder.
4. Pretending you know what you’re doing is almost the same as knowing what you are doing, so just accept that you know what you’re doing even if you don’t, and do it.
Give yourself permission to start. Give yourself permission to experiment. Give your intuition some credit. Give yourself permission to explore what you don’t know and play so that you discover what you don’t know and then get on to the other stuff you don’t know by experimenting. You know how to start something right? So just start, which leads to…
5. Banish procrastination. If you wait more than a week to get an idea done, abandon it.
When I coach teams, I tell them that if they spend more than a week trying to figure something out they are wasting their time and the time of the business. Figure stuff out by doing stuff in small experiments: Build and experiment. If you allow other stuff to get in the way, then the thing you were working on must not have been that interesting or important. Move on to a variant of the thing so that you actually get some value created, which really is the purpose of done … value creation.
I “love coach” friends to look at what people value by observing where they spend their time and money. If it is not spent on you, then it is time to find someone else that does spend time and money on you. It is the same with software products: Spend the most time and money on the stuff that matters most and get it done. Be nice to the feature you don’t like by just dumping it.
6. The point of being done is not to finish but to get other things done.
The point is to create value. The faster we can get one thing done the faster we can get “done done” with other stuff. I coach teams on a pet phrase: “Stop starting and Start finishing”. If you have too many things in process, then nothing is getting done. You might look busy but guess what? You are not providing value until you get stuff done, and you are not effective until you can move on to get more stuff done … so get it done.
7. Once you’re done you can throw it away.
Sure you take pride in creating stuff, I certainly did when I was creating solutions (especially at a startup). But once created, then what? You move on to the next. At some point, the stuff you created will need to be changed. Or it gets thrown away, because requirements have changed. You are not going to get it perfect and you are going to throw it away and build the next version at some point which leads to…
8. Laugh at perfection. It’s boring and keeps you from being done.
It means let the thing go, validate it, move on. Revisit it later when you have more information or have to adjust to something learned. This does not mean you abdicate quality!!! A saying I like is “The perfect is the enemy of the good”. Perfection slows us down and causes us to second guess and create blame. Perfection holds us back from making progress, from getting it in the hands of customers in order to validate what we created.
9. People without dirty hands are wrong. Doing something makes you right.
In lean thinking we are urged to “go to the gemba”, which means go to the people doing the work because they know best how to change HOW we work. Design is not development. Get your hands dirty by doing something.
I want to point out another aspect of this when it comes to “middle management” and I will write another blog on that alone. In Agile, middle management has the super-important role of creating the best possible environment for development, a role that should not be taken lightly. Apply lean principles to help the team succeed by getting your hands dirty. Improving the HOW of how teams deliver.
Read the next post in the series.
by Phillip Cave
Simplicity. Why do we, in general, get so hung up on getting stuff done?
There are two things that I wish everyone could experience. One of them is driving on the autobahn in a Porsche 911 at over 200km/hour. The other is for software engineers to experience building and delivering product from scratch in a technology startup.
If the first wish came true, then I would not be stuck behind slow drivers in the fast lane. It is a PASSING lane people, and I mean pass within the next hundred feet, NOT mile. Pass and move over, don’t police me by thinking I should obey the speed limit (speed limits are suggestions in my mind). Thus, I love the autobahn. Germans know how to drive.
Another wish is for all people in the software world to experience living and succeeding at a product company startup. Like driving on the autobahn, startup companies must move. Startups must get stuff done — or they will not be around. When they finally ship, it is in hope of being successful. My experience in a startup taught me the fine balance of what we now call a minimal viable product.
A couple of years ago I came across this poster at Microsoft about the cult of done. We talk a lot about getting to done, being “done done”, exit criteria, acceptance criteria, and definition of done, definition of ready, and so on. These are all good implementations of the practice of getting done.
Please keep this in mind as you are reading this, in all things we need a goal or target. Getting to done does not mean we don’t think about where we are going, we actually do. It means we create goals based on the information we have today, and then adjust those goals as necessary when we get new information. So with this thought, please read on.
The principles of being done happen to reflect my experience in a startup. My inspiration for what you are about to read below comes from a very simple list in a post entitled the “Cult of Done” and the points in this series of blogs come from there.
1. There are three states of being: Not knowing, Action and Completion
I will only take a moment to discuss the “not knowing” state. Your sole purpose when faced with “not knowing” is to start knowing, quickly. It fascinates me when people batch up work into ginormous requirements documents and treat all of those requirements as the same. Instead they should start working on what they absolutely know needs doing. Then they can figure out what they don’t know by creating short experiments to begin knowing. If a team is faced with considerable risk due to a lack of knowing, that team should start work on experimenting to gain knowledge. You can’t get to done until you start, so start building or start learning what to build by creating experiments. In both those cases, start creating something so you can get to done.
2. Accept that everything is a draft. It helps to get done.
Too often I have heard the words “But we might have to throw it away if we don’t get it right,” to which I reply “…and … <pause for effect>, how do you know it is wrong or right until you get feedback? You can’t get feedback on what the thing should do until you actually start to build it. So guess what, you will have “throw away” work because you are going to learn later what to keep and what not to keep. So quit your whining and get it done.”
I can tell you that some of my most fun in architecting products has been in discovering and saying out loud “… well that was complete crap! Next option?”
3. There is no editing stage.
Well, there actually is, it is when you are typing and you hit the backspace and retype. Other than that, build in small increments, validate in small increments, get feedback in small increments, deliver in small increments … get the idea? Small feedback cycles are much more conducive for achieving success. The longer you edit, the longer it takes to get to done.
In my next post, I share some other principles to ponder.
by Dave Wylie
An Agile maxim is that software in production has value. Requirements and design documents have little to no value. Ask, “Would the customer pay me to do this if they had a choice?”
But there are people in large organizations that work hard every day, making their contribution to the delivery of large systems. They create things like Functional Requirements documents and Visio flow charts, and architecture design documents with associated review meetings and signoff collections. These people have come to believe that these items have value in and of themselves. They probably don’t.
There are two basic reactions when people hear this. One, they experience defensive disbelief. They cannot imagine what would happen in the space between concept and coding without their efforts. Their organizations have delivered software this way for a very long time and it works, they say, and of course their role was important. They have limited visibility into how grossly inflated the costs associated with these activities were as compared to the value of these activities, and how much time and value was wasted in long delivery. Ask what the value is and what purpose the activity serves: The goal of any document is communication. Then ask if there is a better way to communicate in the delivery of products and services. Many organizations have even created audit police forces that demand these non-software artifacts, threatening managers with the bogeyman of jail time for executives if the documents are not created.*
The second reaction is to question their personal value and contribution. These people did exactly what they were told, and were very diligent. But when they see people using Agile principles to deliver code, rapidly and at lower costs, they are stunned. “Oh my, all that work had little value. These people are delivering software all the time, with none of the artifacts we thought were important.” Some folks get re-energized and dive into the Agile teams, looking for how they may apply their experience and expertise. Others leave to search for organizations where they can hide till they retire, ones still mired in silos and handoffs of large batches of non-value adding work.
Agile/Scrum teams need the domain knowledge and experience these people offer. Teams need to understand the functionality of current systems, and how pieces of the organization work together. But Scrum needs it in a lightweight manner, like a whiteboard session or a 30-minute discussion over doughnuts and coffee or some other more efficient mode of communication. The Scrum Team can deliver high quality code frequently, but they need to work on the right things. They can create their own architecture, but it is sure fun to have an architect that wants to get their hands dirty with code that implements a vision and is willing to do what teams do naturally when left to their own devices … experiment in small increments, learn, and deliver. The Product Owner role needs support to help explain the business context, and to know where to challenge the status quo and when to leverage it. The great thing about Scrum is that everyone can see their ideas in production quickly, and know how they contributed to the value of the organization.
So the next time you are asked to create some level of documentation, ask yourself if there is a better way to communicate what the document is attempting to convey. And if you have to meet about the document or get the document approved, then ask if experimenting with a design and having a meeting about whether we are heading down the right path with working product is the better choice for communicating.
* The number of people who have gone to jail for SOX issues is zero. See the Wall Street Journal's 7/29/12 article, Law’s Big Weapon Sits Idle. [Registration required.]
by Dan Ebert
One way to speed up automated test runs is to split them up into groups and run them in parallel.
by Ron Quartel
"This is an informal meeting, not a status meeting, and the presentation of the increment is intended to elicit feedback and foster collaboration.”
— Ken Schwaber and Jeff Sutherland from the Scrum Guide
The sprint review meeting's purpose is to elicit feedback and foster collaboration. It is an inspect and adapt point in the project. When I hear coaches' and ScrumMasters' theories on what should and shouldn’t happen in this meeting, I like to link them back to the purpose.
Here are some of the common anti-patterns, in my opinion:
1. Anti-pattern: The review meeting is where the product owner gets to see the stories demoed for the first time and signs off on them
You could do that, but I don’t like it. Why? Because the delivery team should have already had the chance to find out if it did not meet “done” before this meeting. Leaving sign-off to this late time in the sprint means there is no time to implement any PO-identified delta, and the team may fail delivery of that story.
I prefer the team to do a demo to the PO in-sprint as soon as it feels it has met "done". This follows the pattern of early feedback that we are trying to foster in Agile. If the PO finds some issues or has minor changes (that will not affect the sprint delivery), then the team has a chance to implement them before the end of the sprint. This pattern keeps the PO involved in the delivery of the increment, and fosters collaboration.
Another reason why I don’t like this is because you run the risk of embarrassing the PO in front of the stakeholders if there are issues with the demo. Having the PO see a demo before the review gives the developers a safe environment to do a dry run, and make sure they know how to demo the story. The PO might even describe how he/she wants it demoed differently or only in part in the upcoming review meeting.
2. Anti-pattern: The only stories demoed are the ones that are done
The Scrum Guide says that in this meeting: “The development team demonstrates the work that has been done... The Product Owner explains what Product Backlog items have been ‘Done’ and what has not been ‘Done’”. So, do you show work that has not been “done”? I think the answer to that is up to the PO. If he/she sees value in the work that was done and can see that there is enough done to get feedback, then why not go ahead and show it? Yes, you will mention that it is not as complete as hoped at that juncture, and point out what made it “not done”. Remember, the purpose of the meeting is to get feedback, so if there is enough to get feedback on, show it.
Here is an example: I had a team that deployed software to an embedded system. Part of “done” was deploying the software to a test workbench. Come review day, the one test harness the team had died. The only way to demo was in an emulator. Is that the right thing to do? Yes. You explain to the stakeholders why it is not in the workbench, and will have to resort to showing the progress of the increment in an emulator in order to continue with the meeting. You want feedback and this will get you feedback, so yes, that is the correct thing to do.
3. Anti-pattern: The demo is for the team to see what work has been done
While this might be true, I don’t think it is the primary purpose of the meeting, and not one of the goals. The primary purpose is to elicit feedback from the stakeholders and/or customer(s). A highly collaborative team should know what is going on with the rest of the team during the sprint, anyway. Particularly, if team members are co-located, and even more so if they are pair programming (two practices I cannot recommend enough). I prefer that the entire team watch the sign-off demo to the PO mid-sprint. This might look like, for instance, a pair in a team calling a huddle, and calling the PO to view the work it feels is “done”. The team gathers around and watches the pair explain the finished work to the PO, and are present to hear any feedback or needed changes which might get added to the sprint backlog.
4. Anti-pattern: All stories must be demoed
I feel the demo should be slick, exciting and engaging to the stakeholders. Not all stories are necessary to demo to a room of stakeholders and customers. There may be stories that are run in a sprint that, while necessary to the forward momentum of the product, don't immediately show value to stakeholders. In these cases, I feel a demo can do more trouble than good. Yes, you should mention that work was done, but that is enough for these stories. For example, let's say you have to change the format of the log output so that it can be consumed by the new data mining platform that another project has implemented in the company. You can see how this feature is important -- but in a product that is going to be a user-facing application is this feature an overhead story, or really an end user feature story?
Under these circumstances, I would recommend not wasting time and energy with demoing these types of stories. Remember, you are looking for feedback. Show only the stories that will elicit feedback. Don’t waste people's time. If you can get through the meeting in under the allotted time box, then great!
5. Anti-pattern: The whole team must attend the review meeting always
"What?!" I hear you say. Now, I think that ideally yes, the whole team should participate. But if the room that you have available for the review is too small to accommodate the whole team and all the stakeholders involved, then I would recommend only bringing as many of the delivery team that the room will accommodate. At a minimum you (as PO) should bring the members needed to run the demo if you are unable to do it yourself.
6. Anti-pattern: The overall project progress is not discussed
From the Scrum Guide: “The Product Owner discusses the Product Backlog as it stands. He or she projects likely completion dates based on progress to date.” Too many “demo meetings” I have attended are just that -- demos and nothing else. The meeting is a sprint review meeting of which a demo is just part of the meeting. The important aspect of discussing the remaining backlog is missed, all too often. My personal preference is to bring in a product burn up chart. It’s simple to maintain, and contains the smallest (and most useful) amount of information needed to portray this information. And make it big! Agile likes big and visible and transparent.
Start with the "why"
When you understand the "why", it will help you make the best decisions around any of the Agile practices. I hope these scenarios have helped you get a better grasp of the purpose behind the sprint review meeting.