This is the third in a series of posts about the ongoing Healthcare.Gov saga. In my first post, I suggested that the project had simply too many cooks in the kitchen to be successful. In my second post, I looked at the absence of a “thin slice.” In this post, let’s take a look at something glaringly obvious: no-one in charge.
Most government projects still follow the waterfall software development method. Waterfall projects are typically managed using a common-and-control style of management. As Joel Sposky points out, the command-and-control method, while it works well with 18-year old soldiers, is not the right choice for knowledge workers like highly-skilled software developers.
In a command-and-control system, unlike lean or agile systems that maintain a “responsibility based” organizational structure, some has to be in charge for the system to work.
Despite having having a very large team with over 50 contractors, no one was in charge until President Obama appointed Jeff Zients to take over the failed effort and set things right. So, the government blames the contractors. The contractors in turn blame the government. The contractors also blame each other.
Mr. Zients’ first public move? He elevates contractor QSSI to the lead, and puts them in charge of overseeing the effort.
This is the second in a series of posts about the ongoing Healthcare.Gov saga. In my first post, I suggested that the project had simply too many cooks in the kitchen to be successful. In this post, let’s take a look at whether the project team got some fundamental things correct.
One of the fundamental of agile methods is “thin slicing or sashimi slicing.” According to Andre Dhondt, this is a keystone habit of agile. Ever since, Jeff Sutherland and Ken Schwaber popularized Scrum, the leading agile method, a couple of decades ago, the powerful mental image of “sashimi slicing” has stayed with me.
The basic idea is that we develop systems one “thin vertical slice” at a time. That is, each “slice” is instantiated as a epic or user story (system feature) from end-to-end across multiple tiers at a time: the front-end, middle-tier, and the back end persistence layers of the system. By doing this, we can incrementally build our systems one slice at a time. We can check each slice against a predefined Definition of Done (DoD).
Further, these slices are meant to be driven by the end user experience, and tested rigorously one slice at a time. Clearly, that did not happen with the Healthcare.gov system. So, despite building a relatively trouble-free front-end using agile techniques, the team ran into trouble because they did not thin slice – that is, they did not extend the slice from the UI tier across the remaining tiers.
So, no thin slice, no agile!
The Healthcare.gov site has been in the news since its failure to launch on October 1, 2013. The site has become the colossal government IT failure of this decade.
Sadly, it is proving to be an unfortunate setback for several positive initiatives in the federal space, especially former Federal CIO Vivek Kundra‘s 25-point plan to reform federal IT management and the OMB Circular A-130 with its Guidelines for Modular Development. It appears the team working on the healthcare site was not following federal government guidance established by the Office of the Federal CIO. Now, current Federal CIO Todd Park has been called in to help clean up the mess.
As we dissect the reasons for failure of Healthcare, I for one am hoping that it will serve as a strong lesson on how not to run a large IT program. So, if ever there was a modern-day argument for agile development, it comes from the Healthcare.gov site. On October 23, 2013, I shared my view on the issues with the troubled rollout of Healthcare.gov via comments in an interview with National Public Radio (NPR).
You can listen to the NPR program and my comments here.
Over the next few weeks, I’d also like to share, snippet-by-snippet, the fundamental issues with Healthcare.gov and their debilitating effects on the project and website. Here’s the first one: too many cooks in the kitchen.
Per this Government Accountability Office (GAO) report, 55 companies were contracted to deliver the system (see page 32). So, what happens when you hire 55 companies to produce code? They produce code and they produce code, right? After all, that’s what they were paid to do. How much were they paid? Looks like taxpayers paid in the region of $500 million, and got what each of the 55 companies probably felt obligated to produce: lots of code.
Exactly how much code? Estimates put the size of Healthcare.gov at a gargantuan 500 million lines of code! Okay, I personally find it very hard to believe that the code base is that large, and want to see more data to confirm that number. But, for sure, all those cooks produced an enormous spaghetti-like mess of a system. Make no mistake – this enormously large code base that is unwieldy, buggy and instantly becomes a legacy system.
More to come, but until then, I’ll leave you with this additional visualization of the apparent relative size of Healthcare.gov compared with other large systems. Scroll to the bottom of the page to visualize how 500 million lines of code stacks up.
One of the ways we help companies develop a learning culture is through the collaborative Personal A3 process. The Personal A3 helps employees take ownership of their career development and increases the amount of feedback from their peers and managers.
The Personal A3 is based on the standard A3 process developed by Toyota to encourage empirical learning. A3s identify a problem, analyze root causes, and propose solutions to encourage continuous improvement. They are typically hand-written on A3 paper (16.5 by 11.7 inches) to easily share with others and obtain feedback, and to limit the amount space available and focus the analysis. The book Managing to Learn: Using the A3 Management Process to Solve Problems, Gain Agreement, Mentor and Lead by John Shook and Jim Womack is an excellent primer on the process.
Employees develop Personal A3s to encourage them to think strategically about their strengths and passions in order to develop a career roadmap to track and plan career improvement activities. Ultimately, it encourages employees to continuously improve their skills. Employees select mentors and partners to help facilitate the process and provide feedback.
Ownership Employees are empowered through the Personal A3 process to seek out a career path that is not bound by their current role or dictated by their manager. Most importantly, they are able to sketch a career path that matches their strengths and passions. We often find that employees with a sense of ownership over their career development are more satisfied with their jobs and are ultimately more productive on the job.
Feedback The Personal A3 process establishes a learning feedback loop that allows employees to learn about themselves as they ponder their strengths and passions. Mentors and partners provide feedback throughout the process. As an individual’s career roadmap is implemented, progress toward action items and specific goals are measured and the Personal A3 is revised frequently to reflect learning and progress. Receiving feedback and applying lessons learned are essential for continuous learning.
The Personal A3 is not the only way to create a learning culture. But we find that it’s an effective way to introduce employees to the A3 process, to collaboratively identify and solve complex problems, and to assist them in taking ownership of their career progression and learning from feedback they receive from their peers and managers.
Print out a Personal A3 template to get started!
Read How Can I Develop the Ability to Collaborate?, the Q&A article in Better Software Magazine on which this blog post was based.
Build, measure, learn. Those three words are ingrained in pretty much everything we do here at LitheSpeed. In fact, we’ve been so excited about it that I’m starting to get tired of the “Lean Startup” methodology they describe, though not at all the meaning behind it. We’re incorporating the lessons of Lean Startup to most areas of our business, including our Certified Scrum Product Owner Training and Agile Consulting, specifically with our Lean Product Innovation offering. We’re also launching Build Your MVP, which combines Lean/Agile development and training.
Applying Lean Startup to our work with Sensei was the first step toward all of this. Reading Eric Ries’ book led to an “ah ha” moment, and we refocused on validation/invalidation of ideas, experimented with new ways to get customers’ insights and kept pushing for better ways to gather and use metrics. That learning continues.
The funny thing is that in the midst of our internal Lean Startup craze, we neglected an opportunity that was right in front us. In our company website, we have a golden opportunity to make a real impact on our profits through product discovery. What would happen if we simplify the registration process? Does the registration process even need to be simplified? What smaller changes might have an even bigger impact?
When we relaunched our website as a WordPress site, we based too many of those updates on untested assumptions. We looked at metrics and got some general feedback, but didn’t spend enough time talking to our customers and getting more meaning out of those metrics. We thought the blog deserved prime territory, and that if people read the great content we offer, they’d click on a post and then register for a class or call us in to consult. Did it take long to put the blog on the homepage? No. But the reality hasn’t quite matched that expectation, and we could have found that out much earlier.
The good news is that it’s not too late. By splitting time between existing and new products, we can test different tools and approaches or try the same ones for different kinds of products and services.
This is where you come in. We’re looking for active participants in this product testing. It doesn’t have to take more than a few minutes to get valuable information. This isn’t a survey, though we might try that too. You might actually have to talk to me, because I can learn a lot more about you in a five-minute conversation than a 10-question survey. And if some of you are up for it, I might even ask you to complete a task on the website while sharing your screen. I can get a lot more value out of watching your screen for three minutes than asking you three questions about what you want.
As a participant, you’ll be helping us do what we do better. In return, you’ll see first-hand how we’re implementing the Lean Startup methodology. As we try different tools like Optimizely, CrazyEgg and others, I’ll let you know what’s worked and what hasn’t. I’ll keep you updated on the way we’re working with metrics, interview tactics and more. If you’re interested, email me or check the box next to “Product Discovery” in your email preferences.
Oh, and everyone who dedicates a few minutes to these exercises will be entered into a drawing for one free training and/or a copy of Managing Agile Projects.
As the conversation around the implementation of Healthcare.gov continues, and it’s no surprise that the reason behind the “glitches” has been a hot topic within the Agile community.
Last week, Sanjiv was interviewed by NPR’s Martin Kaste for an All Tech Considered piece on CGI Federal’s role in the situation.
An excerpt from It’s Easy To Blame The Canadians For HealthCare.gov Problems:
“I think that’s grossly unfair. I think they’re a victim of their circumstances,” [Sanjiv] told NPR. He says federal rules require projects to be divvied up among too many contractors — in this case, 54 other companies besides CGI. The idea is to spread the wealth and avoid overcharging. But, he says, it’s no way to build software.
“What folks attempt to do is to use the same model … to build a cruise missile and to develop a smaller software system,” Augustine says. “And it just doesn’t work.”
With back to school and Labor Day behind us, Fall suddenly got a lot busier! At LitheSpeed, things are heating up with several events in the next two months, including:
Lean Startup Enterprise Meetup: Thursday, September 19, 2013. Trevor Owens, CEO of Lean Startup Machine will share his tips and insights on how to build an enterprise Lean Startup laboratory.
Lean Startup Machine Workshop: September 20-22, 2013. Register here to learn the basics of Lean Startup, and how to apply Lean Startup techniques on your own.
Agile DC Executive Summit: October 7, 2013. At the Inaugural Agile DC Executive Summit, several top executives share their experiences with agile and lean transformations:
- Steve Denning, Forbes.com and Author Radical Management
- Mark Schwartz, CIO at the U.S. Citizenship and Immigration Services
- Tracie Winbigler, CFO at National Geographic Society
- Ben Foster, VP Product Development at OPower
- Ken Ritchhart, Deputy Assistant Commissioner and Deputy CIO at U.S. Customs and Border Protection Agency
- Don Sargent, CTO and Mirielle Grangenois, Publisher at The Chronicle of Higher Education
- Max Keeler, VP Business Processes at The Motley Fool
Agile DC General Conference: Tuesday, October 8, 2013 Joe Justice is the keynote speaker. Arlen Bankston, David Bulkin and Sanjiv Augustine will all be speaking at this event, which our VP of Consulting, Bob Payne, organizes with Agile Philanthropy. For more information, visit http://www.AgileDC.org.
Hope those of you in the Washington, DC metro area can join us at some of these events. Perhaps folks from other parts in the world will deem them important enough to travel in.
Have a great, productive and energizing fourth quarter!
In this edition of the AgileToolKit Podcast, Bob Payne speaks with Ellen Gottesdiener and Mary Gorman about their book, Discover to Deliver: Agile Product Planning and Analysis, which focuses on creating a structured conversation around the discovery process. If you want to build the right thing you need to get people together and explore the space, find the value and find a way to confirm.
Below is an excerpt of the interview, but as always, we recommend listening to the whole podcast to learn more about the seven product dimensions and the value of shared language.
But for now, enjoy these highlights:
On writing a book together: “Talk about Validated Learning. It was so powerful: the ability for us to be together doing pair writing and then get very quick feedback.
“We also found another powerful aspect was [actually having] the entire book hanging on walls. And literally having the ability to see this and the flow, or lack of flow. We used a Kanban board for activities. And we really tried, as Ellen and I like to say, we really tried to drink our own prosecco.” – Mary
On Agile requirements: “You know the topics around analysis and requirements are going to be with us no matter what the method of the day is, I mean, it all comes back to ‘What is it that we’re building?’ and ‘When are we going to build it?’ so Agile requirements, or Agile product needs, we prefer to call them “Product Needs” will never go away, as a key issue. We’ve run into teams that have been doing Agile for years and they’re still struggling with issues about requirements and their backlog, and how do they make decisions on what to build. And so the full title is actually Discover to Deliver: Agile Product Planning And Analysis.
“The infinity is of course discover to deliver constantly, and as we move from discovery into delivery we have to know how to verify but also how to validate and use that learning from validation post-release to post-delivery to discover and refine what you’re going to deliver in your next cycle.” – Ellen
On structured conversations: “It’s the ‘goal not the role,’ and our goal is to deliver a high value product, which requires this partnership, equal participation, and ways for them to commonly communicate.
“The structured conversation starts with exploring product options. When we think of the product itself, we think of a variety of options, and exploring what those could be, and yet we don’t time or money to deliver all the options, so one of the pivotal aspects [we consider] is … when we have value considerations that would be used as a filter. So you would have X number of options you filter them through the value criteria and then you narrow that down to the highest value options. So, it’s this explore, and then evaluate aspect, and then we say that the conversation is not over until you have confirmed those high value options.” – Mary
On the actual number of product dimensions: ”What we’ve discovered over the years in this whole world of requirements and analysis is that there’s actually seven product dimensions. [User] stories highlight two of them but there are actually seven. And four of them are pretty much functional related and three of them are non-functional.
There’s the User, there’s Action, there’s Data and Control, Control would include things like Policies and Rules. Those would be the four functional perspectives of the product. Then there are the three that most people would call non-functional: the interfaces, for the user to be able to interface with the product itself. The Environment as well as the Quality Attributes.” – Mary
On the importance of language: “We talk a lot about how words do count in having a shared understanding, which is really what this book is in many ways: helping teams build and sustain and maintain a shared understanding. Often people throw around business domain terms that are not well defined or because you’re at one part of the value stream versus another, they’re not talking about the same thing.” – Ellen
In the agile community, many use collaborative voting techniques to quickly identify agreement or lack thereof. Dot voting is a popular technique used to prioritize among a number of different options. In this post, I introduce a favorite method of mine, Yell Voting, which has similar applications as dot voting, but generates more excitement and fun.
Dot voting is effective for ranking multiple options. All individuals have the same number of votes, represented as dots, which they can spread across one or more distinct options. Each item on the list has to be granular and well understood by everyone, and then the voting begins.
For example, perhaps there is a list of 10 items identified in a retrospective and the team wants to narrow down the list to a couple they will work on. Everyone has three dots to vote on the retrospective items. Some will put one dot each on three different items, others might choose to put all three dots on one option, or perhaps two dots on one option and one on another.
Teams often use stickers and take turns applying them to a list of choices on a flip chart, or they use dry erase pens on a whiteboard to create their dots. There are electronic versions for distributed agile teams.
In many cases, a single round of dot voting will identify the top ranked choices. If not, multiple rounds of voting can be used as the list gets shorter.
A frequent favorite of mine is “yell voting.”
Although I never have seen or heard anyone else using this approach, my guess is that I’m not the first to use it and it might be known by other names. Either way, yell voting is a faster, more energetic version of dot voting used to prioritize among multiple options.
As it’s name implies, yell voting requires, well, yelling.
Like dot voting, we first setup a list of granular choices (e.g. user stories to prioritize) and ensure people have a good understanding of the choices prior to voting. After an option is read out loud and re-explained, the group votes by yelling for the items they support.
If an option doesn’t get much energy, it gets crossed out.
I almost always do it in multiple rounds. For the second round, we look at all remaining options in the list, with the bar set higher for energy level. Once again, low energy options get crossed out. On this second pass, clear leaders often emerge and when they do, they get check marks.
Depending on the list, and the attendees, it can take several passes to go through the list. If we are not forming a consensus on items that should bubble to the top, I often add new constraints, like only allowing each person to yell for three items.
Although yell voting appears to be less precise than dot voting, the lack of precision is not an issue (at least in my experience) when used by larger groups, and the technique becomes a faster, more energetic way of getting fairly similar results. It’s also more fun.
When I use yell voting, there are often a couple of people who will state that it’s unscientific. For example, someone will say, “People who are passionate about a choice will yell louder, and thus change the outcome of the vote.” My response is always, “That’s the point!”
Another concern is that introverts won’t participate. There is a belief that the only way to get introverts to participate is to use silent techniques, like writing ideas on index cards. But I find that the anonymity of the crowd often (e.g. not always) encourages introverts to participate, and increases the probability that they will participate more actively in other discussions. Even introverts like to have fun!
Not An Either/Or
I don’t consider yell voting a replacement for dot voting as it doesn’t work in all circumstances. For example I would use traditional dot voting in more formal environments like a corporate boardroom. I would also use it with a distributed agile team.
Yell voting is not a replacement for dot voting, and just like dot voting, the technique simply identifies opinions. A good facilitator should try to understand the reasons behind the votes.
If you want to try yell voting, a less risky approach is to use it to whittle down an initial list then use dot voting to choose from among the final candidates. If your experience is like mine, you often won’t need to do that final round.
So, try giving it a yell and write back to tell us how it works.
In this episode of the AgileToolKit Podcast, Bob Payne sits down with Ward Cunningham, creator of the first wiki, during the 10th anniversary of the Agile Manifesto. In true AgileToolKit fashion, Bob speaks with Ward about everything from the birth of the Agile movement to the future of the Internet, including the innovative programmer’s Smallest Federated Wiki project.
We recommend listening to the full conversation, here are some highlights in the meantime:
On the original Agile Manifesto team: ”It was actually kind of a happy accident that such a lasting document was produced, but maybe it wasn’t completely an accident in the sense that the people just happened to be the right people and they were all different enough to bring perspective, but they were all aligned enough to be seeing the same goal.”
On the Manifesto’s language: “The fact that it is open to interpretation, the value of that was brought home to me when we tried to translate it, and we asked communities around the world [to collaborate on it]. We said, ‘If you want to do a translation, don’t do it alone. Find the agile community that speaks your language and do it together so that you can come to some consensus on what the right words are, because it’s just not easy.’”
On the Smallest Federated Wiki: “There are a couple things I like to do in a wiki using 21st century components—or at least 2011 components, and that is make it easier to put a rich variety of data types in there. In my original one, I had text and I had images. You know people have added tables and stuff like that but it’s really a textual format, and that makes it at least possibe to co-create and to improve on other peoples’ work. But I see, especially in this open data area, there’s a lot of interest in having very simple formats.
“So what I did was I said, ‘Well let’s just make JSON a wiki markup,’ although you don’t actually write it, you have a drag-and-drop interface that manages a JSON description, and when you edit it you edit kind of at the paragraph level but a paragraph might be an image, it might be data, it might be a variety of data. In fact, the thing that I was trying to visualize yesterday was data that’s geographic.”
“What I think would be interesting is seeing who tends to share data with who, and then that will make a structure of the environment will emerge just from people sharing. We’ll probably have to have hundreds of sites before that really happens, but if that happens then we’ll have thousands and tens of thousands.”
On coding: ”My style is to keep it simple so that I can be wrong and correct it. It’s easier to refactor small code than big code.”
On the future of usabilitiy: “I’m ready to see forms reinvented. Let’s figure out how to have computers without forms. If you think about it, a form is just another form of interrogation… I think talking to a computer should be more like a conversation than an interrogation… It’ll be a little harder to program but not much harder.
“I think what wiki shows is that even if you have something as simple as a place you can write semi-structured text and have it show up on the screen, that people can kind of can get to know each other through that. You can form friendships, and trust, and do work together, so I know the computer interface isnt the limiting factor. It’s really more having an understanding of the kinds of things people want to do and supporting it well instead of just doing the cheesiest thing you can get away with, which is usually just have somebody enter the database fields and press ‘Save’.”
On the evolution of Agile: ”Agile is the accepted methodology, and people are ready to find the next variation of it, to master its intricacies and respond to the computing opportunities that are out in front of us and however we need to organize to do that. I’m glad to be apart of it.”
Again, you can access the full conversation here: AgileToolKit Podcast Interview with Wiki Founder Ward Cunningham.