Monday, June 10, 2013
Mark has helped software companies and IT organizations build strong engineers, produce quality software, and delight customers through a repeatable approach. He enjoys staying current with technology and its application in creating great products. Mark understands and promotes the value of culture and fun in a collaborative work environment.
Wednesday, June 5, 2013
Often we try try to tackle things that are too big to sufficiently understand, estimate, or complete in a reasonable amount of time and we suffer for it. We don’t always see the risks that hide in more complex items and thus don’t feel compelled to break them down. Other times we fail to break things down due to unknowns, ignorance, uncertainty, pride, optimism, or even laziness.
Variation in SoftwareDelivering software products is a constant struggle with variation of size and complexity. It’s everywhere, from the size of user stories to tasks to code changes to releases. It is present from the moment someone has an idea to the moment software is deployed. We strive to understand, simplify, prioritize and execute on different types of things that are difficult to digest. The more variation we see, the more we struggle with staying consistent and predictable.
Because of this variation, we need to be good at breaking things down to more manageable sizes. This need is so pervasive, I propose it be viewed as a fundamental skill in software. I don’t think most teams recognize this and certainly don’t develop the skill. Many people on Agile teams exposed to concepts like Story decomposition don’t often realize how often they need to apply similar practices in so many other ways.
Why Decomposition MattersMy example of eating small bites was simplistic. In developing software, there is a lot more to gain but it is still ultimately about reducing risk and making tasks easier.
ProgressAccording to The Progress Principle, a strong key to people remaining happy, engaged, motivated, and creative is making regular progress on meaningful work. Not surprisingly, we want to get things done, but we also want to feel a sense of pride and accomplishment.
Of course, stakeholders and other parties are interested in seeing progress from those they depend on. When we are able to make more regular progress toward goals, we provide better measurements and visibility for ourselves and others to know how we are doing.
It should be no surprise that smaller items enable quicker progress toward goals, if done right. We certainly need to take care to avoid dependencies and wait time. Smaller, more independent goals allow more frequent progress and all the benefits that come with it.
CollaborationAs we have more people working on something, is it easier to put them all on a larger, more monolithic task or divide and conquer? Usually we prefer to divide and conquer. Yet how we divide is important as well because dependencies and other kinds of blocking issues create wait time and frustration.
Decomposition can be one of the easier ways to get additional people involved with helping accomplish a larger goal. By breaking up work into more isolated items to be done in parallel, we are increasing the ability to swarm on a problem.
Complexity is one of the greatest challenges in software development. With more interactions, operations, and behavior,s we are more likely to have edge cases and exposure to risk when anything changes. Large goals are easier places for complexity to hide. The larger the task is when we try to accomplish it, the more details we have to discover, understand, validate, and implement.
Focusing on smaller units of work can be a helpful constraint we place on ourselves. Why add our own constraints? When we constrain ourselves to work on a small portion of a larger task we are trying to limit the complexity that prevents us from accomplishing something. We want to avoid a downward spiral of “what if?” and “we are going to need” scenarios that, while important, can slow the task at hand and lead to overthinking and overdesigning and accumulating work we may never need. We are trying to avoid Analysis Paralysis.
ControlBy looking at Kanban systems we can see wide variations in size can impact lead times. If we can be more consistent with the size of items flowing through a system then we will have more consistent throughput and cycle times. By breaking down work items more frequently into items of similar size cycle times become more stable and the average size (due to whatever size variation remains) becomes more useful for forecasting due to the law of large numbers.
ClarityIt isn’t a coincidence that Break It Down is also a slang phrase appearing in music and pop culture that also relates to our goals. Urban Dictionary defines “Break It Down” to mean: To explain at length, clearly, and indisputably. By looking at the pieces of a larger whole individually and in more details we can often gain more clarity and understanding of the bigger picture than if we had never spent the extra effort.
SummarySoftware Development is a continual exercise in dealing with variation of size and complexity. From early feature ideas, to low level code changes we have work that can be difficult to understand, manage, and predict, especially when it is large. Decomposition helps us make this work more manageable.
So, we need to remember to Break It Down. It is all about decomposition. And in software, decomposition is everywhere, yet so many struggle with recognizing the need and applying it well. I believe decomposition should be considered one of the most fundamental and critical skills in software development. Getting better at it takes a combination of discipline, practice, and learning but can pay off immensely.
To be effective, even this post required decomposition. We are going to continue with a series of posts exploring many of the individual types of variation in software and how lean/agile teams cope with these different situations.
Tuesday, June 4, 2013
Here is the problem: Something is going to change.
What if half way through the month a new higher priority feature is assigned to the team? Do you take someone off of their feature and absorb a switching cost? What happens when the developer goes back to their original feature weeks later? Do you double the load of your best developer and ask them to be a hero?
What if instead of starting all 6 features at the same time we just started working on 2? What would be the impact to change now?
By swarming the team on a few problems and working collaboratively (instead of in silos), not only do we get the benefit of less Work in Progress allowing more agility to absorb changes, but we also benefit from increased knowledge transfer.
Wednesday, May 29, 2013
Coming together is a beginning.
Keeping together is progress.
Working together is success.
Dependable, reliable, and consistent
Asks "What can I do to help the team succeed?"
When observing the best teams, it is difficult to identify leaders.
- The creative type who generates ideas called the Plant
- The extrovert who has good networks (the Resource Investigator)
- The dynamic individual who thrives on the pressure (the Shaper)
- The person who soberly evaluates the usefulness of ideas (the Monitor-Evaluator)
- The cooperative team player (the Team-worker)
- The ones with specialist skills (the Specialist)
- Those who turn ideas into solutions (the Implementer)
- The person who get issues completed (the Completer-Finisher)
- The person who keeps the team together effectively (the Co-ordinator).
Tuesday, May 7, 2013
- Review the scope and understand the stories
- Task the stories
- Reviewing Epic or MMF (Minimally Marketable Feature) stories and breaking them down into Sprint Sized Incremental Stories
- Having conversations with the Product Owner (PO), Stakeholders and/or customers to understand their needs and working with the PO to document the Acceptance Criteria
- Discussing new stories and providing a rough sizing estimate so they can be prioritized
- Thinking about what will be needed to implement the story: New HW or SW? New Knowledge? New Architecture? Paying off accumulated Technical Debt?
- Working on just enough design to keep things flowing. It is common for UX Designers to work about a half a Sprint ahead of the rest of the team.
This edition of the annual DevOps Days event in Austin (which also takes place in other cities each year) was declared the biggest. There were great discussions, Ignite talks, and Open Space sessions as well. And while there is always much conversation around technology, there was a noticeable focus on culture.
Many of the talks on both days had a strong cultural component. On the second day, the organizers even mentioned feedback from some attendees to move past the culture stuff and on to tech talks. But it was obvious from the sessions that a large number of people felt the cultural conversation was important. Those of you in the Agile community who haven’t looked closely at DevOps will recognized these are similar conversations to those occurring about Agile in general.
Some notable takeaways:
- Patrick Debois on The future of DevOps - slides/video
- DevOps State of the Union by John Willis
- John Heintz tweeted that DevOps is 90% attitude (culture, meme) and 10% technology
- Pete Cheslock had a talk on DevOps in Your Job Title Is Doing You Harm
- Jeff Hackert had a talk on Exploiting Conway’s Law for Underpants and Profit
- Gene Kim, one of the co-authors of The Phoenix Project, spoke on How Do We Better Sell DevOps
- Speaking of The Phoenix Project, it was referenced in many talks and obviously making an impact with many. It is a novel about DevOps and Business and highly recommended.
- Sharing a Culture of Automation - Instant Infrastrucutre in Developing Nations by Chris McClimans
If you haven’t attended one of these events, you should definitely try to attend at least one they put on each year.
Monday, April 15, 2013
Behavior-Driven Development (BDD) employs the approach of specification by example. Instead of talking in abstract terms about what the system will do, the team collaborates to create specific examples that specify what the system should do from the user's perspective. These executable specifications function as acceptance criteria for the user stories the team is developing. The team specifies as concretely as possible what the specification is, and then the developers code enough of the system to make the test pass to satisfy the acceptance criteria for that specification.
Cucumber is such an amazing BDD tool because it’s so good at mapping stories and acceptance criteria to automated functional tests. Product Owners and BA's write acceptance criteria in business language. Developers and testers unobtrusively automate tests for them.
Taught by expert instructor Paul Rayner, coauthor of the upcoming Addison Wesley book, BDD with Cucumber, this 2-day hands-on workshop is designed to get you productive with doing BDD with Cucumber in the shortest time possible.
Day 1: Introduction to BDD
- Introduction to agile background and process
- Feedback loops: vicious & virtuous
- Building quality in
- Understanding the place of BDD - the agile testing matrix
- Outside-in testing
- Why test automation?
- Build the right product using specification by example
- Creating a ubiquitous language
- Writing scenarios with Cucumber
Day 2: Creating Value using Cucumber
- Using Cucumber for using specification by example to test web applications
- Best practices for Cucumber test scenarios
- Dealing with scenario data
- Adopting BDD with Cucumber - emphasize learning and focus on value
Who Should Attend:
All delivery team members:
- Testers and QA staff
- Developers (Ruby, Java and .NET)
- Project managers
- Product owners (Business Analysts, domain/subject-matter experts)
- Software architects
Attendees should bring a laptop for the class coding exercises. A pre-configured virtual machine image will be provided for class coding exercises.