Tag Archives: scrum

  • -

How Healthcare.gov could have saved billions of dollars and been delivered in 1/2 the time.

Tags : 

By September 2014 spending on the 15 state health insurance exchanges and healthcare.gov will climb to over $8 Billion dollars*. This huge expenditure for health insurance shopping sites could have been avoided if the federal and state governments had mandated and followed modern software development practices.

onebillionincash

$1 Billon USD. We’ll need eight for healthcare shopping sites.

How did the governments, on something as high profile as healthcare reform, decide to use a risky 40 year old process to manage the delivery of the health insurance exchanges?

Comparisons were made between healthcare.gov and amazon.com, yet the way in which these two websites are developed could not be more different. Healthcare.gov used the phased or waterfall approach with 55 different contractors responsible for different aspects, and no one responsible for delivering finished product. Amazon.com uses Scrum, an Agile approach that emphasizes small cross functional teams who deliver working tested features every 2 weeks.

To understand how a website like healthcare.gov could have been delivered using the Amazon.com approach, I created a short illustrated video. This video demonstrates, in a simple way, how to deliver a site like a health insurance exchange using a fraction of the budget in about half the time. These techniques are very similar to how companies like Spotify, Google, Square, Valve, Salesforce, Amazon and many others manage getting software development done.

Got a few minutes to save billions of dollars on software development?

I hope you like this talk, please subscribe on youtube if you are interested in future videos. If you are looking for in person training for yourself or help for your organization, please contact me:

https://www.innovel.net or http://www.scrumtraining.com

Cheers
Robin Dymond, CST

*Health and Human Services data

*Report by Jay Angoff on Health Exchange enrollment costs per state


  • -

How Spotify Works. Agility with 1 product and 1200 people

Tags : 

Scaling Agile at Spotify. What True Organizational Agility Can Look Like.


Henrik Kniberg and Spotify released an illustrated video on how Spotify is Scaling Scrum and Agile from a 1 team startup to a 1200 person powerhouse of the online music industry. Spotify is a disruptive force in the music industry, forcing record companies, radio stations, and artists to rethink their business models. Spotify is also an Agile company from the ground up. Spotify got its start using Scrum with one team, so there has been no “Agile Transformation” for the company. Instead the company faced the problem of how to maintain the Agility they had with one team while growing quickly.

The video describes their team structure, the organizational structures that span multiple teams, and the key principles that guide their decision making. I think it is fantastic that Spotify was willing to open the Kimono and show the world how they work, and that Henrik, as their Organizational Coach was able to present it is such a compelling visual way.

This is the cutting edge of organizational agility. For most companies, this kind of organizational model is a fantasy, it is so far removed from their current organization’s structure. If I were a music company executive, I would be scared as hell. Instead, I look forward to continuing to help companies achieve their own improvements for Agility in their own business context.

Part 1 of How Spotify’s Engineering Culture Works


  • -

The Agile Hardware Design Mindset.

Tags : 

Moving to Agile development in hardware is more about mindset than it is about technological limitations. Let’s consider some of the limitations that are often used to resist Agile hardware development, and show how these limitations are more to do with thinking then with technology.

PCB board design and layout.

We can’t do Agile because we need to complete the full board design before sending the design for PCB fabrication and population of parts. Manufacturing is costly and takes a lot of time, so we want to minimize these costs.

Let’s examine each of these points:

Myth: Manufacturing a PCB takes a lot of time.

Facts: The last 30 years of continuous high speed innovation in PC motherboards and mobile phones has driven the PCB manufacturing business to be very quick and responsive. A five minute search for fast turnaround PCB manufacturers revealed many companies that can turn an 8 layer PCB in 24 hours. With overnight shipping, you can have your PCB in 2 days. If you plan ahead with the manufacturer to get parts ordered so it can be populated, this can be done at the same time.

Myth: Manufacturing a PCB is costly.

Facts: The costs for quick turn around PCBs are trivial when compared to the cost of an engineer waiting for hardware. You can calculate costs from a variety of quick turn manufacturers at http://www.ladyada.net/library/pcb/costcalc.html For a 3″x5″ PCB the highest cost for a 2 day turn around was $215, shipping included. For comparison, that average loaded cost of an engineer to their employer is (salary, benefits, office, etc.) is $80-200 per hour. An engineer who spends one day waiting for hardware is far more expensive then the fastest most expensive quick turn PCB manufacturer.

Myth: We need to complete the full design.

Facts: A well designed PCB is modular, with modules for CPU, memory, I/O, RF, etc. Each module is designed as a unit, with interfaces to other modules, just like software. Therefore we can design a module, or part of a module, and that completed design can be treated as a testable deliverable. For example, the CPU and the memory could be designed and shipped as a populated PCB ready for developers to start using. The developers can start to use that platform for coding while the hardware designers work on the next module. The hardware designers will need to implement some features, like a JTAG or USB port and terminate some pins so developers can use the PCB, but that is a small price to pay in exchange for getting hardware into the hands of the software developers.

Deploying iterative and Incremental hardware development.

If we change how we think of hardware from being a single physical device that has to be designed, to a set of functional modules that are deployed as hardware, then we can map the manufacturing process of PCBs to the deployment of code into production. If we can deploy functional modules into a physical device (PCB+parts) in a few days, then we can deliver hardware functionality using an iterative and incremental approach. For example we could deploy a PCB with a basic input output (I/O) circuit that meets our simplest design criteria. This circuit would be deployed into hardware and then could be used by developers for coding and testers. If it is determined from programming and testing that the simple I/O design needs changes, a revision of the I/O could be completed to make the desired improvements. This ensures that the designers are delivering a design that meets the needs of the developers and testers. Once the developers and testers were satisfied, the I/O could be evaluated by the customer to gain their feedback and ensure it meets their needs.

Iterative and Incremental firmware with the hardware.

If hardware is thought of as deployed functional modules, then firmware is the glue that enables these modules to provide customer value. Firmware engineers have numerous well understood options for software development when there is no hardware. Software simulators, emulators, evaluation boards, and FPGAs all provide different options. With every design there are business priorities and technical risks. Based on these risks and priorities the developers need to figure out how to slice the design into components of firmware and hardware that will deliver the most business value and risk reduction with each iteration. For example if I/O is risky then the hardware and firmware developers should figure out how to build, code and test the I/O module before the CPU module. For example this could be accomplished using an I/O PCB that interfaces to a CPU evaluation board.

Using business value to drive product design.

We are faced with the continual expansion of software into the hardware space. Shrinking device sizes, massive gate arrays, generic open source platforms like Arduino, and smart phones all are changing the hardware development game. However software will always need something to run on, and as more devices connect to the internet, the importance of real world interfaces will continue to expand. Great hardware developers like Hewlett and Packard always emphasized getting out of the lab and meeting your customers. As hardware is increasingly used to wire up the connected world, it is more important than ever that hardware designers find ways to quickly respond to the changing needs of their customers. Agile principles and values provide good ideas to help you get there… just replace the word software with firmware or hardware :).

PCB Art by Artist Steven Rodrig
Artwork “Post Apocalyptic Data Hunter: RONIX” by Steven Rodig at PCBCreations.com


  • -

After 12 billion pound healthcare IT failure, U.K. shows that governments must adopt Agile and have their own delivery organization.

Tags : 

With the massive failure of the healthcare.gov launch in the US, people are talking about why such an important software development initiative turned into such a failure. The US however is not alone in these kinds of failures. The UK government spent 10 years and 12 billion pounds on the failed NHS-IT electronic patient records program. Now 12 billion pounds is about 16 billion Euros or 20 billion US dollars. Ouch! I picture the Queen in earlier times shouting “off with their heads!” Instead the UK government started listening to people who knew about Agile and technology development. The UK Government has created the Government Digital Services, GDS, a 300 person department with the skills to deliver digital services online. In a recent interview with NPR, Mike Bracken, head of the UK Government’s GDS discussed the successes the GDS initiative has had in the two years since it was formed. Bracken mentions many Agile principles GDS are using to deliver a government that is digital at its core. Some of the highlights are:


  • Optimizing for business value: GDS is only going after the processes and services most used by citizens, such as passports, tax filing, benefits, etc. Within these areas they further optimize, so GDS is delivering digital versions of the highest value services first. Some processes and services may never be automated because the business value is not there, and that is OK.
  • Incremental delivery: GDS is delivering services in an iterative and incremental fashion. They are not trying to get it all right the first time. Instead they are getting the most important parts right, and then learning what works and what needs improvement.
  • Cross functional teams: GDS teams are cross functional, with developers, process and policy experts, UI designers, testers, etc.
  • Collaboration over contract negotiation: GDS has thrown out all of the traditional procurement processes and procedures. Instead of building contracts based on some wild ass guess wrapped in 300 pages of documentation, GDS admits they have no idea of where or what they need to do in 3, 5, or 10 years. Instead they focus on working collaboratively with users and stakeholders, quickly (1-3 weeks) delivering small amounts of working tested software to their users and getting their feedback.

Bracken was visiting Washington D.C. to talk to government officials and influencers to help them understand how the UK government is bringing digital services in a fast and cost effective manner to its Citizens. For everyone’s sake, I hope the bureaucrats in DC are listening. The $600 million spent could be a more cost effective lesson than the UK, or it could be a failure that is repeated over and over, just like in the movie Groundhog Day.

Read or listen to Bracken’s interview on NPR here.


Article on the UK Government’s failed NHS-IT program

US healthcare costs in the are rising disproportionately compared to quality of care, what are the options to solve the problem? For Profit or Single Payer?
US healthcare costs in the are rising disproportionately compared to quality of care, what are the options to solve the problem? For Profit or Single Payer?


  • -

Video: Booting Up Customers to Build Great Products

Tags : 

This is a video of a talk I gave at Agile Tour 2011 in Vilnius Lithuania in October 2011.

Your New Customer has no clue what Agile is, however they have lots of assumptions about how they will “get the product done.” Do they know how to work effectively with you? Do they know all of the business and user issues that the product will need to solve and how to solve them? Have they built a product like this one before? Are the 100% committed to being the product owner or do they have other jobs too?

We’ll discuss how turn a customer into a Product Owner, from the first meeting to creating the first backlog, through to one year into development. We’ll go through key learning points that your new Product Owners and teams will have to transition through, and techniques you can use to make your life and theirs easier. Come prepared to learn tested hands on techniques you can apply in working with your customers.


  • -

Should scrum team members talk directly with customers?

Tags : 

A recent discussion on linkedin was started based on the question: Should teams talk directly with users or customers?

It provoked me to write the long response below.

“What do you mean by customer? Do you mean user? Sponsor? Another manager?

The Product Owner (PO) should be representing the various stakeholders for the system being built. The PO should also be creating alignment among the team and the stakeholders as to what needs to be accomplished in the release. This is a balancing act between the various needs, business and technical. The PO is not an information hub, everything doesn’t have to go through the PO. A good PO creates alignment around the vision and the solution, and steers based on their ongoing learning and subject matter expertise.

So I’d split my response into the stakeholder groups:

For users:

In general it is a good idea for a Scrum team members to talk to users. As Geir Amjso mentioned, the PO can become a bottleneck if they try to control all information. Also their maybe some nuance that a user can provide that will help a developer understand the problem more clearly. This conversation is framed in the context of a sprint and is about clarification and understanding to implement the solution.

Another benefit of having users and developers interact is that spark of innovation. Innovation happens when people with tools and techniques really start to understand a problem. Users sitting down with developers creates empathy and helps teams become motivated to provide pain relief or innovations that surprise or delight.

For sponsors:

Not a good idea without the PO around. The sponsor is usually more concerned with the high level issues and the politics/expectation management for the product/project. The sponsors should engage the PO, and if they are going around them to the team, there is something else going on.

For other managers:

It depends. It may make sense if there are dependencies with other teams/vendors and the team is managing those issues within the sprint. It may also be an end run around the PO to get work done that is not planned in the sprint. In this case the team should refer them to the PO.

Scrum does specify meetings where interactions between teams and customers are more formal. However Scrum says nothing about restricting communications to the Scrum meetings. If communications are restricted to these meetings only the team will be slower and have less opportunities to learn. As a Scrummaster the goal is to get great software developed and do it with the highest level of engagement from all parties. This means there are lots of communications that should happen on an ongoing basis between all members of the project community. A Scrummaster needs to enable work to flow from request to working software, and this involves maintaining the flow of information. Will their be deviation? Sure, however the Scrummaster is there to detect when the team or the stakeholders are getting off track (i.e. adding scope, changing direction, etc.) and help them stay on track.

Sure you can talk to the team! Take a seat!


Sure you can talk to the team! Take a seat!


  • 1

Dude! Where’s My Backlog? The People and Process of Product Ownership.

Tags : 

In September 2010 I gave a keynote talk at Agile Eastern Europe called “Dude, where’s my backlog?” The talk covers the common pitfalls seen with Product Owners and the Product Backlog. The talk covers the people that bring a product backlog into existence and the processes they can use to maintain it. This includes using ideas from Kanban for personal process and modifications to Scrum for more frequent involvement of the team in maintaining the backlog.

Robin Dymond Keynote: “Dude, where’s my backlog?” from Agile Eastern Europe 2010


  • 3

Agile User Interface Design and Information Architecture from the trenches

Tags : 

I was a technology Director in a large web design company 6 years ago, and they failed to adopt Scrum. There were numerous management dysfunctions, however the Creative managers were the most resistant to change. Often this resistance was a case the creatives not wanting the reality of building enterprise software to hinder the design concepts they were making in Photoshop or Illustrator. When these design concepts met the reality of enterprise architectures on the development floor there were major implementation problems. This dysfunction, along with high pressure, unrealistic delivery dates and long hours resulted in missed deadlines, high stress, low code quality, and 40% annual turnover in IT staff. Being at this company for a short time spurred my interest in User Interaction design (UX) and Agile, and I have since found basic solutions that work when people want to do UX and Scrum. To date (2011) I would say that of all the disciplines needed for creating software and especially web sites, people coming from UX background are often the slowest and most resistant to adopting Agile principles and practices. I think this comes in part from the influence of Allan Cooper’s book “The inmates are running the asylum.” However Allan Cooper, himself a practitioner looking for solutions that work, embraced Agile and Scrum since 2008, if not earlier.

Here is the way I work with UI Designers and Information Architects who want to work Agile:

    1. The Product backlog and its priorities drives all the work. We work from business priorities not UI priorities.
    2. Sketch the highest level level UI for the site. No drill downs into buy flows, just top level.
    3. Look at the backlog and start thinking about what the team will need for UI half an iteration ahead.
    4. Make paper prototypes (sketches, paper menus, paper buttons) to support upcoming user stories for next sprint. Don’t embellish with new features the designer thinks are needed. KISS. Include validation and other acceptance criteria for data fields.
    5. Create and maintain a style guide and reference it as required. Create and use reference page templates as required.
    6. Combine 2,3,4 above into a 1 page design spec. to support the UI needs of a user story.
    5. Review prototypes with PO, QA and lead dev a few days before sprint planning, ensure they think it is good enough and it is testable. Keep notes regarding potential trade offs.
    5a. Check in design docs, version them.
    6. Participate in sprint planing with rest of team.
    7. Work with team on implementation, clarify details of design (dimensions, locations, behavior, etc.). Work with QA on test plans for new UI. Help build UI (HMTL/CSS/PHP/Javascript etc) in dev IDE, pair with dev as they wire it up. Pair with QA to run test cases and implement automated UI testing (see tools like Rspec, Cucumber, etc).
    8. repeat for every sprint.

To recap the UI designer starts half a sprint ahead of the team, helps the Product Owner with UI issues, and creates very lightweight and flexible prototypes as input to sprint planning. The rest of the work is done within the sprint. I have found this is “just enough” lead time to have thought through UI issues without creating solutions in a vacuum away from the team.

Additional tactics:

  • Create a style guide for the team and have them read it, listen to their feedback and continuously improve it.
  • Create templates: every page is not a unique creation. Refer to those templates in prototypes and design spec.
  • Break dependencies between UI/layout and business logic at beginning of the iteration. Agree on data/fields/controls at beginning so business logic can be rendered to a very simple layout free page.
  • Test your paper prototypes with users by asking them to do certain operations and then observing the resulting actions. Don’t worry about big usability testing at end, do it often and informally with people who are easy to access and know enough about that business.
  • bad idea ui tool

  • AVOID COMPLEX HIGH FIDELITY USER INTERFACE DESIGN TOOLS. They really slow you down and lock in decisions far too early. These decision are often wrong.

Lack of detailed knowledge about the customer needs and technical limitations can result in an unstable UI. This lack of understanding results in an unclear product backlog and user stories coming into the sprint. To cover these gaps the UI person has to go find out the missing details to create the design, which slows them down and results in numerous design changes during the sprint. The UI designer is making up for lack of knowledge or lack of effort on the part of the Product Owner. Fix this root cause by getting the Product Owner to improve the product backlog so the designer and the team have better user stories and acceptance criteria coming into the sprint. User Interface work is simply another form of software requirements, as are software architecture, features, and test plans. All of these activities can be done in a “just in time” and emergent fashion and result in consistent architectures and usable interfaces. As User Interaction designers it is important to focus on the end result, great software, and to help the team realize that goal. The UI design artifacts: wireframes, clickable concepts, specs, etc. are often over-valued by UI designers. These are tools in our toolbox and are not essential. Choose the tools and the collaboration model that takes the least amount of time and offer the greatest impact on the goal of delivering great software. That goal is best achieved by working side by side with team members building the software. Many are doing it today. However it does require people to change their behavior, and that is likely the hardest thing to do.


  • -

Oracle, databases, Scrum and Agile

Tags : 

I recently read a great post by Cary Millsap, an influential member of the Oracle community on Oracle and Agile. I have read both of the books Cary mentioned, they are excellent, and the Goal by Eli Goldratt is outstanding, if you haven’t read it, put it at the top of your list. It is a novel and has nothing to do with software.

I don’t really understand why Agile is not embraced by the Oracle community. There are lots of reasons why it can make a developer’s life better, and it doesn’t matter whether it is coding SQL or Java. However from a DBA perspective, I think having changes committed to production DBs every week or two is scary, especially if you are the one carrying the pager and responding to 4 AM outages (and why do they seem to mostly occur at 4 am?).

For Agile to be successful we need to deploy early and often. For production stability and performance we need to quantitatively know deployments are going to work just as well or better than the last deployment. There need to be safeguards put in place to address the risks, and systems that reduce or eliminate the transaction costs of doing deployments. As mentioned in Cary’s post, automated testing plays a huge role here.

Here’s one way of stating the DBA’s needs in the form of a user story:

As a DBA I want to have a stable, high quality database to monitor performance and tune so that I can maintain data operations and improve system performance.

Acceptance Criteria:

  • New database releases to production must contain all the performance improvements implemented in production to date.
  • All DB changes must have automated test coverage that quantify whether or not the DB changes implement the desire inputs and outputs correctly
  • Any DB change found to not function correctly can be rolled back without impacting the rest of the DB
  • All changes between production deployments are automatically calculated and displayed to DBAs
  • Production Databases are stable and not changing between the regular release cycle.
  • DBAs collaborate with and are consulted by the team(s) implementing DB changes
  • DBAs provide weekly mentoring and DB code reviews with team members implementing changes
  • (Please add your additional acceptance criteria)

What changes you would need to implement in your organization so that the above user story were true?

If you are a DBA working in a small company next to developers and QA, then maybe it is changing a few of your practices, working more closely with the other developers on DB changes, implementing test frameworks like DB Unit, getting SQL code into version control, implementing a DB change management tool like Liquibase, and creating a better rollback strategy.

If you are in a large bank sitting with 15 other DBAs at the backend of a manually intensive, form driven, cost managed, outsourced deployment process, you have some work to do :). The goal and many of the steps are the same as with the small company. Ironically, the bank has many more resources to implement these changes. However the management hierarchy and organizational silos make it much slower and more difficult to implement these changes. So what do you do? Well you can continue to stay in your DB team silo, complain that Agile is the problem and be the victim. This means that most interactions with others wanting changes will be negative, you will be viewed as obstructionist, and that cute tester will think you’re a jerk. Another approach would be to remember that we are all on the same team, and go for a walk and meet the Agile teams to see how you can work together. You might take this blog and the user story above, show it to the ScrumMaster, Product Owner and Developers. Start a friendly discussion about how your needs for a reliable, production friendly DB can be met in the context of regular production releases. Remember that by doing this you are asking them to change as well, and since you are both changing, the situation becomes problem solving together. One more point, expect mistakes to be made and occasional firefighting on the road to a more effective development and database operations process. The changes are non-trivial, the results can be amazing, and the journey is the most memorable part of the experience. Bon Voyage!

Thanks to James Thomson for the inspiration on this one.


  • -

Kangaroo boxing: Scrum vs. Kanban.

Tags : 

Software development has its trends and its innovations. The term Agile came about because people practicing different iterative workstyles decided to come together and develop a brand, Agile, that represents their common principles and values. Agile workstyles include Scrum, eXtreme Programming (XP), Crystal Clear, Feature Driven Development (FDD), and Dynamic Systems Development Method DSDM. Then people like Mary and Tom Poppendeick recognized that Agile software development could benefit from the ideas of the Toyota Production System, also called Lean for western implementations. Now some of the proponents of Lean, many of them from the Agile community, have been attacking Agile methods like Scrum, claiming that Lean is “better.” To me this doesn’t make sense. Agile and Lean ideas are complementary. Ideas from Lean come from manufacturing, so applying them to software development requires care and understanding of how software is different, and why. More importantly however, the conflict goes against the spirit of Agile, and does not do the software development community any good. It drives a wedge and a barrier where there should be none. It causes proponents of either camp to ignore or resist good ideas from the other. Primarily this conflict seems driven by personalities in the community who see personal gain and status with attacking another’s work. The idea that in a community of thinkers one can gain reputation by putting down other proven and legitimate ideas is false. Gaining reputation in a community of thinkers such as software development requires that you show leadership in new ideas AND in integrating new ideas with proven ideas already in place. The battle of Scrum vs. Kanban reminds me of kangaroo boxing… Richard Attenborough narrates…