I would like to highlight three key outcomes that applying Lean UX can bring to your agile teams. Let’s start with the base understanding of “Better Together”. These shared learnings come from my Lean UX workshop where I provide coaching for teams to practically and tactically adopt this new paradigm.
If you have been mastering the agile disciplines in your engineering practice, but have not connected your UX Designers and Researchers into the mix, you are missing some significant gains. You are leveraging the best of one practice while being dependent on incongruous processes that feed into your Agile projects, causing a less than robust agile practice. There is a clear and present need for the engineering process to be aligned end-to-end. By joining forces with all cross-functional teams, you can realize the ultimate goal of creating experiences that customers love.
Bringing the best practices of Cross Functional teams together.
Engineering spans “Thinking It” to “Making It”, yet most companies set up systems that tailor their processes to the different aspects of engineering. When builders participate in parallel with thinkers, they achieve contextual understanding together, which frees up the need to lead by documentation. No hand offs are needed, as they know what to build; they were an integral part in conceiving of the project. This dramatically reduces the need for things like redlines, specs and demo reviews that ordinarily take great effort throughout the process, as real-time communication is so much richer. In every case that I have experienced, life is better together when all participate together in an agile methodology with Lean UX principles and Design thinking applied throughout.
DIAGRAM: How it all comes together.
DIAGRAM 02: Working together from End-To-End in an Agile manner
This blending of two seemingly different disciplines, mindsets, even objectives of the same product only becomes strengthened as they participate in interdependence throughout every stage of the process. In the give and take collaborative creation of the idea through to the thing itself, each participant learns from the other SME (subject matter expert). And each gains deeper understanding of the why’s involved. Firsthand experience by both types of talent in the engineering process in the thinking to the making removes the need for documentation to lead and dramatically reduces the “lost in translation” phenomena. I have found that when the team plays together in each other’s worlds – the divisive behaviors end, the comradery and buy-in increases and a joint passion for the projects and product enables the teams to deliver a much higher quality experience. Shifting to this interdependent “better together” model is the beginning for teams to transform beyond normal performing.
Part 2 will cover the Lean UX principle of “Getting out of the Deliverables Business” and hopefully add a little more clarity around what that actually looks like.
Part 3 will focus on “Experience Outcomes“. I have become convinced that this is the most valuable principle of them all.
So stay tuned!
Blog post submitted by Bob Payne, VP of Enterprise Consulting, reflects on the legacy of Jim Weirich.
This past February the Agile and Ruby communities lost a very influential member. Jim Weirich died on February 19th. Jim was involved in the creation of many things that the ruby community now takes for granted; Rake, RubyGems. Github honored him with a special message for his last commit on the [Wyricki project].
Unfortunately I only met Jim one time. However, I do have a podcast as a memento of that meeting. Back in 2007 I spoke with Jim at the RailsEdge and wrote the following intro to my podcast. You can listen to the podcast at AgileToolKit.
Here is a short excerpt from the interview:
“I spoke with Jim after his Rake Talk at the RailsEdge. If this is not your favorite build tool now it will be. Jim is the creator of Rake and the RubyGems package management for Ruby. These two tools have made my life a lot easier and if you have not used them, then you are probably not using. Jim talks about using Rake and db migrations with a recent java project.
I also spoke with Jim about ruby test driven development. It was great to see someone do tiny step TDD in a presentation that was not an eXtreme Programming demonstration.
Jim is the first of my guests to say “You’re the AgileToolkit Guy…I listen to the podcast!” or something to that effect. Thanks for the interview and for listening to my podcast Jim.”
There is now a scholarship fund set up in Jim’s name for computer science students. With this fund we can help carry on the legacy of teaching that Jim showed in his lifetime. More information about the fund can be found here:
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