I like this article but tend to disagree with the individual contributor attending in place of the scrum master. I’m not sure how one individual contributor would know what the entire team did.
I like this quote: “it is almost impossible for leaders to over communicate project vision and it is a critical step for effective leadership”
It seems like the term ‘inertia’ has become washed-out in The Noughts, just as the term ‘paradigm’ was overused late in The Nineties. I often hear inertia as the key culprit for nearly every business problem encountered in the past 25 years. Inertia in this case can be defined as the force that keeps people and processes behaving in the same ways, even in light of superior methods. While there’s no doubt that changing the behaviors of 6.5 billion people isn’t going to happen overnight, not all problems can legitimately be blamed on this mystery force of forward momentum. In fact, as a general rule, one should question and further scrutinize any situation where the basis for some problem has been associated with ‘intertia’.
For instance, I’ve had several conversations where the creation of various roles in a business has been deemed questionable and mostly likely a product of corporate inertia. While this may be true in some aspects, especially with the standard approach used in handing out titles, there can be no denying the power of specialization in this process. If enough individuals existed with all the abilities to engineer, market, sell and support a product, market forces would soon push this new wave of white collar workers to the top of the food chain. Unfortunately/fortunately, these superhuman workers do not exist in significant numbers; thus, the need for most existing job roles continues.
Another similar situation often blamed on inertia is the existence of management within large institutions. Is the existence of VPs and CxO positions at Google a product of inertia at the enterprise level, or is this approach just the reality of not having a better system of organizing large numbers of people to accomplish a similar goal? If there has ever been a chance to rethink common ways of doing things, I believe Larry and Sergey would have found and promoted a different way. If innovation is the nemesis of inertia (and I believe it is), Google would be the Jedi force facing the Sith-based corporate mandate.
In general, pinning the responsibility on the ‘inertia effect’ will typically provide little help in solving a problem. In fact, blaming inertia will most likely provide a red herring excuse for giving up on attacking a problem due to the overwhelming nature of tackling such a mystic force. Looking for smaller solutions to problems and taking baby steps to tackle a larger problem will lead to much more productive solutions, and in many cases, these smaller solutions may lead to the generation of superior methods which alter the state of the bodies in motion.
There are occasionally some odd situations that transpire during the Agile planning process, and one question that frequently arises is how to stay releasable when certain features cannot be broken down into releasable code prior to the ship date. Ideally, the basic Agile tenets are observed before starting to classify something as out of the ordinary: nightly builds of fully installable and executable software, small increments of working software delivered (2 weeks), continuous testing, and etc. Even if a team is following all of these, there can still be some situations where the team cannot complete a feature to a point where it can be delivered to a customer. This could be a situation where the small increments of the feature, while working independently, do not add up to enough value to complete a useful workflow, or the team may have incorporated some 3rd party tool or product, which instantly overwhelms the team with integration test cases. In these rare cases, teams are left with the question of how do we keep the software releasable but continue working on features which may not make it to the customer’s release. The following list provides some ideas to combat this problem:
- Hide the functionality. This option could include several things such as hiding a tab (via configuration or unreferenced URL) with the incomplete functionality, but allowing access to the product owner, developers, and QA, so that testing can occur in the main branch of the software. It could also involve licensing, where a license key prohibits the customer from accessing the uncompleted parts of the product.
- Wait on delivering the 3rd party product. Even though the team may have spent vast amounts of time implementing new APIs and testing the new product during the release, the incorporation of the new 3rd party product should be constructed such that it does not prevent the rest of the product from shipping.
- Limit the selling points. While it’s never a good idea to have visible parts of the product which are not fully usable by the customer, the important point is to make sure the rest of the product continues to function properly. If other useful parts of the code can be delivered to the customer, the customer may want to take advantage of the other fully working functionality, and this is what should be promoted.
- Document unfinished workflows. As with the option above, release notes and known issues can documented where the product is lacking. With both of these last two suggestions, the limited functionality should not create additional problems nor allow the user to sabotage himself.
The next time you hear someone warn ‘if it ain’t broke, don’t fix it’, perk your ears and pay attention because dire straights may soon follow. The rate of change is increasing and what’s working today will be broken tomorrow because someone else will be doing it better, faster, cheaper, and with less effort. As the title of this blog declares “Continual Improvement”, this is the mindset necessary to compete, and frankly survive, in all areas of life today. (I was going to mention rapid globalization and technological advancement, but the double cliche was more than I could stomach.) Here are some examples:
- Don’t see any issues with your smooth flowing work process? Wake up! One of your competitors is or soon will be using the same process with 1-2 tweaks to increase productivity two fold.
- Think you know everything there is about programming language X? There’s 10,000 people connected to the Internet working to develop faster than you with an 8086 and for the same cost as an 8086.
- Does the significant other seem quietly content with the weekly routine going on X years? Wait too long to throw some spice in the mix, and breakup city will be in your future moving plans.
The point is just thinking something isn’t broke means it probably is. These complacency thoughts should be the trigger in the mind that jolts us out of our slumber and starts probing for better ways.
Decrease your iteration length. – The Agile answer to how to overcome the problem of breaking down these seemingly large requirements. At first, it sounds simple, but after giving it some thought, it sounds like a Greek philosopher’s answer to the meaning of life. (i.e. Neat answer, but what do I do with it?!)
The two dilemmas that teams face when breaking down requirements are (1) a reluctance by software engineers to develop in a (perceived) less-than-efficient mode and (2) how to use multiple people in a common area of the code, where the ‘9 mothers and a baby’ theory starts to show (no pun intended). I won’t go into all of the ROI reasons to offset both these fears because they are well documented in any Agile process book; however, there are some different ways to brainstorm the large requirement question.
In general, decreasing the iteration length may be taken in its literal form. If using a 4 week iteration, switch to a 2 week iteration. If using a 2 week iteration, the team might experiment with fully accepted story cards within a 1 week iteration. Assuming the team is already using a 2 (or less) week iteration, another way to consider the breakdown is by considering what would be done if only 2-3 days were given to accomplish part of a larger task and demonstrate some progress, no matter how small. Unless the answer is ‘give up and quit’, there is some part of the requirement that can be done in a shorter period of time. As stated before, the team must trust the counterintuitive notion that this approach will not result in the most productive use of everyone’s time.
Since many problems are too large for one person to code within one iteration, it only makes sense to use multiple software engineers. One way to look at using multiple people is to consider a drastic approach of being forced to solve the problem of how to write a ‘say hello’ program with equal participation from 3 people. While a completely ridiculous way to solve this problem (not to mention a ridiculous problem), each person could rotate typing the code on a single keyboard. The point is to highlight that every problem could be broken down (components, classes, methods, etc.), and once again, the team has to make a leap of faith that the paybacks in familiarizing multiple people with more of the code and the benefits of demonstrating working software will make the team more efficient over the long term.
Last but not least, teams can approach the requirements breakdown phase as a mental competition. While many engineers like to exhibit their problem solving skills, the team can make the breakdown process a problem in itself. Peer recognition and other forms of compensation can be added to help change the old mindset of cranking out code to put food on the table. In this case, the baby gets new shoes when high quality code is delivered frequently and not when the super engineer works 24 hours straight to code something no one else understands, which will take 3 weeks to test in the quality.
This article about excessive overtime in the IT industry reminded me of a question I was asked about how meet a release date when the project was behind. While there are many things to try, asking the team to work additional overtime was low on my list, and here’s why.
Anyone who has worked in the software industry for any amount of time knows that releases can and often do have highs and lows in terms of work hours. If the team has been cohesively formed, development and QA engineers will most likely work extra as the release date approaches anyway. While a last extra push over a couple of weeks or so might help cleanup a few last details, the effects of doing this for many weeks will often cause the project to be delayed even further. This is because tired and burned out engineers will make more mistakes, which will create more churn and code chaos. In addition, if any team members quit before the release is complete, the project could take a serious setback and potentially fail. So, what can be done? Fortunately/unfortunately, there are three fundamental things.
- Decrease scope. If the project is using an Agile approach, this won’t be an issue because the team will maintain a releasable state for the majority of the project. Some will often mention decreasing the quality, but this is essentially decreasing the scope since releasing a quality product was a requirement in the beginning.
- Adjust resources. Adding people is a favorite suggestion for second and third level managers to make, and it never hurts to reevaluate the team. Unfortunately, software isn’t the same as building a highway, and in some cases, the additional resources can consume time from the key contributors and stretch the release date out even further. There are some interesting variations on this suggestion ranging from adding subject matter experts to help the existing team all the way to adding resources in specific areas, such as testing. With an Agile approach, resources are typically fixed, but if there are multiple Agile teams, some teams may be able to take tasks from another team that has encountered roadblocks. In addition, if the Agile teams have been formed over time as cross-functional teams, it becomes much easier for alternate teams to be able to take on extra tasks with minimal training time.
- Push the release date. If no compromises can be made in either of the first two areas, moving the date will be required. When using an Agile approach, everyone agrees to the three laws of software development, often referred to as the iron triangle, and in this model, additional iterations will added until the desired scope is achieved.
There are many jobs that a product manager may do, and while most focus the vast majority of their time gathering requirements and selling the products to the sales team, I contend that another equally important role is necessary. This role involves selling the engineering team on the value the new features or changes in the product will have for the customer (and ultimately the success of the group). In other words, for a product to be successful, the engineering team must be motivated to implement the product manager’s feedback. Many projects have failed or been plagued by engineering feature creep because the team did not have confidence in the information stream coming from the product manager(s).
One way to motivate engineering groups is with statistics and objective data showing the value to the customers. Ideally, revenue projections per feature would be great, but this is on par with predicting the weather. Another approach is showing raw historical data on the number and names of customers who have requested a feature; furthermore, having historical revenue data for what each customer paid would be a welcomed bonus. Information like this would provide teams with some objective justification as to why priorities have been set and take the obscurity and mystique out of a proposed new feature set. Unfortunately, this information rarely seems to make a backlog or requirements document. It could be as simple as keeping a spreadsheet with the top 25 features and noting the customers who requested each feature. In addition, it seems like a good sanity check for the product manager to validate intuitions and cross check with others in the company.