by Kathy Simmons
Learn how unique SolutionsIQ is and what differentiates us from our competitors! We have a depth and breadth of Agile talent and services that you won't find anywhere else.
For greater insight our culture, check out these videos of recent company gatherings!
by Steve Kuo
We are commonly asked how big our tasks should be. That should be a pretty simple question to answer. How big is too big for a couch to fit into my house? Simple -- how large are your doors and does the couch come apart? Determining how big our tasks should be is a little bit more complicated than that, though.
How big is too big for a task on an Agile development team? How small is too small? How would Goldilocks pick a story that is “just the right size”? In a lot of ways, the answer is do what works best for the team. With that said, what we’ve seen work very well across many different teams in many different industries is: Keep your task size to one day or less. Breaking tasks down to one day or less exposes enough detail to define the boundaries, but not too much design to constrain ideas and take a lot of time to plan. It also seems to help mitigate estimation error as well. There are some costs and risks involved with breaking tasks down this small though.
People are notoriously bad at estimating the time and effort that any task will take because a significant part of the estimation process involves intuition. Domain/subject matter experts and experienced senior people can provide slightly more accurate estimates, but they are not significantly better than those of less senior technical people.
In some ways it’s as much human nature to want to know exactly how long it will take to do something as it is to not be able to answer that question accurately. We’re bad at it but we need to do it, so how do we work with it? By balancing the duration of the time estimate with the amount of time it takes to define the work. The greater the time, the more likely our time forecast will be off. And the more time it takes to define the work and the greater detail we design, the less efficient and adaptable we are when we implement the work.
This is why breaking tasks down to one day or less works well. Doing this lowers exposure and lessens the risk of bad intuitive guesses. Limiting task size to one day or less lowers the amount of time affected by our innate inability to accurately predict work and effort, while increasing possible feedback cycles and visibility. The discussion and knowledge required to break tasks down to one day is enough to expose problems that would cause the task to take longer than a day. When a task is mis-estimated and goes longer than a day, it generally spans multiple stand-ups and becomes visible to the team. This feedback gives the team an opportunity to reflect, adapt ,and offer help. The amount of time that the task breakdown discussions take, although initially longer, tends to quickly be acceptable to developers.
There are some caveats to breaking down tasks to small sizes, though. When breaking down tasks to one day or less, it often takes conscious thought to not design and get distracted and go “into the weeds” while tasking. There will be many “small” tasks to track and maintain. This is a necessary evil, though, and while this can be a bit tedious it does increase visibility/accuracy and shortens the feedback loop. Initially, breaking tasks down to one-day chunks will take a little extra planning time, but as the team becomes more practiced in this skill it will become second nature and not take longer.
by Dan Williams
In a recent TED talk, noted philosopher Baroness Onora O'Neill addressed what she considers a faulty viewpoint concerning the concept of trust. In her opinion, the claim that there has been a great decline in trust is without factual basis. Further, based on this faulty assertion, people recommend that our goal should be to have more trust.
Ms. O’Neill went on to say that all of these ideas were misconceived, and that the claim was mere opinion and could not, as far as she knew, actually be substantiated. We seem to trust and distrust the same folks we always have. We generally distrust politicians and journalists and tend to trust nurses and librarians. Her point is that we trust others based on what we know of them. And this is entirely reasonable.
Secondly she states that the goal of having more trust is off the mark. We don’t need to simply increase trust in others, but rather find people who are trustworthy. We don’t need to trust more, we need more people in whom we can trust. Who are these people? Well they are at least competent, honest, and reliable. And they need to be all three.
So how do we establish trust? Empirically! Through observation over time. People doing what they say they will do. People delivering with prior agreed-upon quality. Trust is one of the identified values which informs an Agile approach.
Jeff Sutherland, one of the creators of Scrum and a signer on the Agile Manifesto is quoted as saying,
“To create high-performing teams, agile methodologies value individuals and interactions over processes and tools. Practically speaking, all of the agile methodologies seek to increase communication and collaboration through frequent inspect-and-adapt cycles. However, these cycles work only when agile leaders encourage the positive conflict that is needed to build a solid foundation of truth, transparency, trust, respect, and commitment on their agile teams.”
I believe that Sutherland and O’Neill would agree on both the method and the goals of Agile. Vulnerability is good evidence of trustworthiness. My assertion is that Agile, as a mindset not a set of methods, succeeds or fails based on establishing our trustworthiness as individuals and teams who consistently deliver value to our clients.
by Pam Dyer
Leading technology organizations are transforming the way they manage their server environments by using software automation rather than manual administration.
On December 10, Ben Tomasini — SolutionsIQ Software Developer and Agile Coach — presented Agile DevOps: Environment Automation. He walked through a working example of this practice using Chef, Vagrant, Berkshelf, and other industry-leading tools, with special focus on the use of Test-Driven Development and Continuous Integration.
You can use the sample codebase Ben employed in the webinar to jump start your own Agile DevOps practice.
Agile DevOps: Environment Automation from SolutionsIQ on Vimeo.
by Phillip Cave
Continuing the “Principles of Done” series, this post explores the difference between being effective, efficient, and busy. (See Parts 1, 2, and 3.)
A story I like to tell is about working with a group at Microsoft. One of the PMs I collaborated with had a team that was faced with an ever-changing environment and specialty-based team members. During a standup, it was brought to the team’s attention that a story was blocked because the specialty team member was busy setting up his test environment. The team asked if he had to be the one to set up the environment. The answer was no, he did not have to be the one to set up his test environment and that, in fact, another team member could accomplish that task while he unblocked the team by working on the story.
Was it efficient for him to set up his own environment? Probably. Was it effective? Absolutely not. This is a story about focusing on the work and not the team member, and reaching the most effective way in which to complete the work. Teams have work and people to complete work. Adding to the complexity, teams sometimes have multiple types of work to perform.
Focus on the most important work and then focus on the most effective means by which to complete that work. This may mean examining a buildup of work in front of an activity and understanding why that buildup exists. It may mean changing how you do work or who does the work, or removing your title and focusing on getting work done. It may mean pairing team members to advance the team’s collective knowledge around a technical domain, a business domain, or both.
When I was at Premera Blue Cross as an internal business process consultant and later an IT leader, I was fortunate to be asked to participate in the Lean leadership program that the company had instituted. I learned many things in that program. Chief among them was how the operations leadership team approached maximizing the effectiveness of paying claims. The operations teams had a large visible matrix of activity and people (the activity title on one axis and team member name on the other). This simple tool allowed leadership to examine at a glance the progress they were making to get team members cross-trained in all areas of the claims model line value stream, so that when a claim came in the door it could be handled by one person (or as few as necessary). This was so that the claim could be paid as quickly as possible without having to hand it off into another queue of work and sit idle wasting precious cycle time.
Use this same principle. Work should not have to sit idle or experience a diminished value for lack of effective approaches to make the work flow.
In a recent coaching engagement, I heard about a team leveraging the efficiency of their software engineers — they were more expensive and the team wanted to handle the cost more efficiently. I asked what was more important. Was it more important to optimize on a title or the product? My advice to them was to think of it economically from the perspective of the product. Sunk cost already exists: You know you must have a certain type of software engineer, for example, so that cost is already incurred. The next order of business is to invest in delivering product effectively vs. using a resource efficiently just because they are paid more. You pay them more because you must pay them more based on market demand. The next economic factor is producing product with the people you have in the most efficient manner possible. It is a choice to be effective at the product level instead of being busy. You can optimize the title or you can optimize the product delivery or a combination thereof. Optimizing on someone’s title is at the expense of the product. Optimizing the product or a blend thereof is NOT at the expense of someone’s title. It may be a matter of pride, but the real goal is for a team effort to ship the product.
It is not more efficient or less expensive to optimize a resource if it means the product is late in shipping, because you incur opportunity costs and miss out on the increased cash flow that shipping would have provided.
Your individual contributor may be happy in the short term at the expense of the long-term goal of the product and that of the company. Given this, it is a wise use of a developer’s time to focus on other activity (such as testing, for example) in order to get the product to a shippable state more quickly.
When you do this, you end up managing the work-in-process to stop starting things and focus on finishing things. Getting to done means focusing on the right activity at the right time to deliver and be done.
In a future post, I will discuss other factors that contribute to not getting done. These include:
- “Carry-over” stories
- Defining acceptance criteria
- Planning for support with project work
- Unclear direction
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?