At this point it was clear. Inserting some flexibility or "shades of grey" into our development path would have an impact.

There is an old adage of engineering managers that says "Schedule, features, and engineering funding. You pick two and I will set the third." When you really think about this statement it's almost humorous.  Imagine a sales leader saying "revenue, sales expenses, products to sell. You pick two and I will set the other." Sales would always be "successful" but your company would also be bankrupt.

The key was to find a way to put some "grey" into the system. We had precise knowledge of the features we needed. Our engineering team size was set. And we had a fixed date for delivery.  Success for our next product feature set was pretty much black and white. What we needed was to insert some grey into the path to get there. This is management in the real world.

First, we set a realistic goal that everyone believed was challenging but achievable. We carded (Agile) and prioritized the work. The traditional method of Agile was to add cards (work) when we encountered unanticipated tasks that need to be completed. These work additions were crushing our schedule so we implemented a group review and approval process before any new cards (work) could be added to the project.

If these cases either simplified the design or reduced the scope in a way that wouldn't impact core features they were included. But we scrapped cards that moved us farther away from our goals. This process was incredibly successful.  What we found was that with more team interaction from architects, engineers and product management we were able to find a way to reach our goals.  In some cases we found more simple solutions. In other cases we eliminated non-critical work. When necessary, we constrained the scope of use for some features.

In the end, is was all about team interaction and building a more flexible and interactive development process. In true fashion, it came down to working smarter, not harder.

 

Comment

Read More