Businesses and Silver Bullets

I’ve been teaching Lean Process Improvement or Six Sigma for about 6 years now. I’m getting into learning Agile in a pretty deep way through reading a ton of books, seeing it in action, and working with Agile teams. I’m currently learning Business Architecture/Enterprise Architecture as well. All of these methodologies are similar but different in some dramatic ways. Lean itself isn’t a project management solution, it has some features of it, but the goal is to take action put something in place and measure the results. Inherently, you’re supposed to be done as soon as possible. Six Sigma has some pretty strong Project management capabilities built into it, but it’s not to be used to install software or some other type of function, it’s design to solve a complex problem, prevent it from happening again and moving on. Agile is totally about managing projects while with as little overhead as possible, while maximizing visibility. This is done through frequent light weight touches and less frequent demos. Finally business architecture is about defining the structure of the business then identifying root causes. I’m the least impressed with Business Architecture at this point because it seems to have the objective of keeping the people at the top in charge while minimizing the amount of empowerment throughout the organization. That’s just my first brush with it though and I could be wrong. The other methodologies are all about empowering the team and the people doing the work so they can be as effective as possible. With Lean and Six Sigma the goal is to eliminate your own job if you’re an instructor or internal consultant, it doesn’t seem the be the case with Business Architecture.

Regardless, all of these methodologies indicate that our businesses are extremely sick. It’s becoming pretty clear to me that the vast majority of current state business practices are flawed and leading to under performing businesses. Lean Six Sigma, makes it clear that there are out dated and poor performing processes. Agile makes it clear that traditional software development doesn’t work and is much too expensive. Business Architecture indicates that no one knows what people are doing, why they are doing it, or where other parts of the organization are doing the same type of work.

In many cases some of the problems looking to be solved by Business Architecture are eliminated in a true Lean organization, but not always. I believe that is why Lean Startup methodology is becoming so popular in both new and old businesses. It’s a novel way to force change in an existing company, while in a Startup it helps keep the company healthy much longer. Furthermore, it forces the company to build effective organization structures early and continually test them.

With the majority of businesses being unhealthy due to out dated processes or aging systems, it’s no wonder why organizations are always looking for a silver bullet. They need a quick fix because nothing is working correctly. The goal to continually drive more and more profits prevents leaders from taking a hard look at what they are doing. Forcing investment in doing the right thing the first time or to do the right thing for the organization even if it takes more time and potentially money.

With my current process improvement classes and engagements I’m seeing a continually struggle between the way you should do Lean, focus on changing what you can, and the reality that most of the work is being done through systems. Even if I wanted to improve processes around the system there’s a limit to what I can do, because I cannot effect change on the underlying system. Changing those systems either IT or organizational can be impossible to do without a strong organizational will and clear strategy. Without either of those, any improvement or agile effort is doomed to fail.

Methodology, managers, and projects

When working on a project there are a few different ways to manage those projects. One is the traditional waterfall approach, which is your top down project where you have to use Gantt charts to figure out how long you think it’s going to take up front, where you’re given a set date that can’t change without a lot of effort to do a certain amount of poorly defined requirements, and a set amount of money to do the project. This approach has been how Windows and many video games have been produced in the past. It’s not really extremely effective and really no one really likes working a project conducted using Waterfall methodologies. There are risks, projects get cancelled and the project management can seem to be capricious and opaque. This leads to lack of trust and belief that management has the best interest in mind for both the project and the employees on the project.

To address these concerns a group of people created the Agile project management methodology. The goal was to value working software over documentation. Which means that each bit of software is broken down into the minimum viable feature, or the smallest piece of working software that could be packaged and used by a customer. The goal is to manage the project through adjusting how many of these features are going to be finished by the go live date. Effectively you build small bits of work instead of finishing one giant massive piece of software.

This approach is effective for other types of technology that have a modular architecture. There’s some minimum viable product, where you need a minimum set of features for the product to actually work. For example a cell phone needs to have a combination of features to function properly. Things like bendable screens would not be in the minimum viable product, but an excellent touch screen would be. These minimum viable features can be modulated based on the Kano model – which is useful for determining if a specific feature is basic, a pleaser, or a delighter. If the feature falls into basic, you must include that feature if you’d like it to be a success. However, those minimum features don’t guarantee a successful product, you’ll need to include pleasers as well as delighters. Those are the pieces of scope that you will be able to eliminate to make sure you actually launch the product on time.

Issues with these projects come whenever there is a mixture of methodologies. When management believes projects must be managed through waterfall through a central project results office while the development team believes the project is being managed through the agile methodology. This creates serious issues whenever there is miscommunication, lack of information, or lack of understanding the real status of the agile team’s approach. This is exacerbated by the required openness in the agile approach (where you are supposed to continually learn from your mistakes and have a conversation about all the problems you’ve had – to fix them) while in waterfall it is better for people to hide and place blame elsewhere whenever things are not going well. Not because people are bad, but the incentives are in place to behave this way. With a single option of go/no go, it’s better to minimize the known risks as if things are misunderstood as going poorly it will drive management to take action. While in an Agile team, discussing the true status of the project is vital through self policing and partnering with other agile teams to address the problem. The greater the likelihood of success of the projects.

This conflict and a switch from governance in the agile methodology can and will destroy the trust the various agile teams have developed. An organization needs to fully commit to a single project management methodology or it will struggle to complete any project within scope and budget and will demoralize the leaders of projects being worked in agile, as waterfall would likely be the methodology that management selects. Leaders of Agile projects should leave organizations that undercut the agile teams, as it will not stop and will have dramatic impacts on their careers in the long run.

Starting from the Bottom, building an app

So, aside from blogging, watching (and playing some) video games, and obviously reading what else am I working on? Well, I’ve got a few things cooking. A friend and I are working on an app for smart phones as well as the web application version.

Who isn’t working on an app these days? Well that’s a seriously good question, it’s pretty easy to get started. I found that the idea was one of the easier things to come up with. Especially since the starting point wasn’t mine, it was Jesus‘s, a really good friend of mine from the Netherlands. The basic premise started with wanting to build a social networks to help kids find other kids to play with.

However, we’ve since evolved the concept into something that parents would want to use for their kids. We’re envisioning an app that will help kids deal with being diagnosed with Diabetes. Managing diabetes through an app isn’t a novel concept, the American Diabetes Association has one already as well as a support group with forums online. Hell they even have dietitians and RNs to help support the forums. We’d have none of that at launch.

Our goal is to enter a slightly different space, helping the adults learn how to teach their kids how to manage the disease. So this puts us in a different space. Furthermore, we don’t think that apps alone will help manage the disease as we believe that there needs to be something to continually engage the kid or parent to continue using the application.

To this end we plan to eventually extend to games and other things that would tie into our application. Those are still in the works and I think our key idea, an avatar, will help when we launch.

So where are we now? At the very beginning. My development skills are way out of date and not so relevant for this project, so I’m learning how to develop in Ruby on Rails right now. I’m using the book Agile Web Development with Rails 4 to do so. I’m  a big fan of this book. By the time I finish walking through the book I’ll have developed a Store Application (to sell the book no less).

Even beyond that though, I’ll learn how to manage a full application in Ruby along with all the database structures that go with it. It’s pretty much ideal for developing the back end as we determine how we want the front end to work. Furthermore, Ruby plays really nicely with JavaScript, CSS, and a few other languages. So, we’ll be able to continually evolve our front end well beyond the initial Rails application.

This will allow us, as developers, to build a fairly consistent application feeling across platforms. I’m not building this alone, as I mentioned Jesus is helping me and he’s doing more of the administration of our server, DB, and has started on a UI for the app version.

We have a long way ahead of us, but we’re using an application called Trello to manage our agile Kanban work items. This allows us to pull the amount of work we believe we can do in a week. Have a conversation about the work we’re planning on doing, and then demo the work that we’ve done so far (see image below).

Kanban Board


These tools have allows us to move forward at a modest but consistent pace. Jesus is currently pursuing both a PhD and an ice cream business, while I’m working, buying a house, writing blog posts, and kind of working on a fantasy novel. So we’re both busy guys but we’re making head way. It will take time, but I think no matter what happens, it’s going to be worth the effort invested into this project.

By the way, the app’s name is going to be Monster’s Versus Diabetes. I think it’s a pretty sweet name. I’ll post updates as we go through the process. Feel free to shoot me any questions about agile, kanban, or managing a project like this.