Moving Visibility and Measurement Up the Ladder

More visibility up the organization ladder

A couple of the benefits Agile has given us is adding visibility into team work and moving us away from individual measurements, as our primary way of measuring progress, issues, etc. For example we replaced individual tasks estimates with team velocity for forecasting completion. This visibility into the teams work and measurements of that works helps change a teams focus to how do we improve our ability to deliver value to our customer as often as possible. Measures of a team are not enough to help most organizations transform and learn how to deliver value more often. What we need to solve this issue are visibility to how the organization/system works and measurements that help management see where the system has issues so they can make these visible to the the teams to help guide them to make good team adjustment. This is where I see a great benefit in concepts, principles and practices from Kanban, system thinking, theory of constraints and Lean.

Agile visibility

Scrum/XP/iterative planning help a team visualize many aspects of their work. By looking at trends and collaborating closely teams can make incredible improvements. This type of working can also improve communication up and down the business hierarchy. However, many problems are outside the teams control and though the impact of those problems are made visible the exact cause and full understanding of them are not made visible. Management needs visibility and measurements to help them see where the system is causing organization and team problems.

Another issue is a team improving, yet not understanding their impact on other teams. Sometimes a team improving can slow other parts of the system down hurting the ability of the organization to deliver value sooner. It is also possible that management does not understand the impact a 'lower value' product has on a higher value product. Due to the 'lower value' of the product on its own a lower level investment in the product may actually slow down a higher value product. Management needs visibility and measures that help them improve how they manage the system. It is a change for much of management from managing people to managing workflow (paraphrase @alshalloway or @agilemanager??? sorry could not find the original tweet on this idea).

This visibility will also help teams understand what they need to do differently as well. If I do X it hurts team Y. How can we deliver and reduce the burden on other teams. How might we help other teams such that the organization can deliver value sooner.

System visibility

Kanban, system thinking, theory of constraints, and Lean ideas are a good way to see this higher level.

A Scrum team may see that their velocity is inconsistent which indicates a problem. Maybe that problem is something the team can fix, unavailable product owner, missing/weak skill set, no automated safety net, etc. However, when these are not the issues they may not know the full cause and more importantly managers do not have a good view to the cause of the issue. Add a visualization of the workflow across teams with WIP limits and now management can see that a team is waiting on another team. They can see a team is producing work that another team cannot integrate with until much later causing a lot of rework and defects for both teams.

Scrum teams may be effectively delivering each iteration/sprint but they cannot always see the effect of their work on others. If managers and teams are looking at the cycle time of work that goes across multiple teams they can make decisions to improve how the organization delivers.

Conclusion

Too often managers are pushing teams to improve some metric that is outside their control. This causes frustration and gaming the metric. Scrum gave the team transparency but the work of the manager needs to be made transparent as well. @agilemanager recently tweeted "I'd like to end focus on process and refocus on management (training). #Kanban is a management method not a process" Agile/Scrum/XP have visualization mechanisms and measurements that help teams see issues they control and effects of things outside their control and Kanban adds visualizations and measurements that help managers see what is the cause of the problems outside the teams control. I would also like us to move away from focusing on process to focusing on managing the work and finding the best way to deliver value. Lets move past just making team work transparent and measuring teams and make workflow and system issues visible to everyone and use the measurement trends to move us towards a common goal.

Collaboration Not Compromise Or Control

Why aren't we seeing the value we expect from our agile implementation?

Many of the agile implementations I have seen struggle with achieving the value they set out to achieve. One of the big reasons is we replace collaboration with compromise, control or some combination of them. Collaboration Not Compromise or Control could be another way of stating the agile value of People and Interactions over Process and Tools, I am not sure, this is a work in process in my mind. I believe collaboration is that 'thing' we are striving for that will give us the best chance at achieving the outcomes we are seeking. This wording comes from thoughts and ideas I have been reading from @alshalloway, @flowchainsensei, @drunkcod and others. Being that this is work in process please help me work this out and smooth the flow of this idea.

Most would agree control is not collaboration (I think)

Control is violence against the individual. It assumes the worst in others and seeks to minimize the effects of the persons expected 'badness' by limiting the individual as much as possible. @flowchainsensei has a great set of blog post on the ideas of non-violent communication at http://flowchainsensei.wordpress.com/.

Sometimes command and control can have some good outcomes but they are becoming fewer as complexity continues to grow. I believe it is also wrong to look only at one outcome and not its effects on people. Outcomes must be good to and for individuals if they are going to be sustainable. 

Compromise is (usually) not collaboration either 

Compromise is often the majority acting violently against the majority. A recent tweet by @drunkcod made the statement "Compromise is Latin for 'everyone loses'". We usually want compromise when we are not in control so that we get some say in how things are done. Compromise also means you give in to my ideas.  Compromise is someone giving in to someone else or someone else's ideas. Compromise is violence imposed on another person with the use of nice words. Putting it in another way, compromise is control via manipulating others to go along with you.

Control and compromise are not the same thing but quite often lead to the same poor results and are usually bad for people, individuals.

So what is collaboration?

I think collaboration can be explained in a couple of examples. I take the first example from an @alshalloway tweet, which occurred during a conversation about coming up with a set of practices that fit your context, "I've been saying this for a long long time. XP, Scrum, Lean, Kanban, hybrid (5>2)". If a team has the experience from all of these methods they are likely to be able to find a process that fits their needs and context. This is the type of collaboration we need, not only creating the right system to work in but also making other decisions. It is not compromise, though potentially someone with a strict we must do these practices this way may think it is.

The second example of collaboration comes from a common goal and set of principles. Collaboration is difficult to come to by when we only understand a set of practices. In the midst of the same conversation which turned to fixing dogmatic implementations of Scrum, @alshalloway made the statement "we don't (fix them) -they fix themselvs once they understnd what they need 2do. following practices not as good as understandin(g)".

It also requires the idea that we are going to make some prediction about the expected outcome of a certain set of actions and then adjust when we are wrong. When we are only implementing a set of practices, a few things hinder us from collaborating. The first is we are closed to other ideas. Secondly, everything that is not practice X looks like compromise to us. Thirdly, we have trouble looking at the outcomes critically and leaving open the fact that the practice we believe in is part of the problem.

Conclusion

Collaboration is where we can achieve good things. Don't get me wrong, it does not guarantee good things but enhances the possibility of good things happening. Collaboration is also a much better place to be in as a team member.  Collaboration requires me to give up control. It avoids violence by being open to learning from others, taking all ideas, experiences and knowledge and turning the combination into something better. It avoids the violence of control as well.

Thoughts?

Stuck in the Past or About to Be

Experienced software developers seem to get stuck in the past and less experienced developers repeat the same mistakes that caused the experienced developers to get stuck. This is not absolute truth but it is a pattern I see way too often. The sad thing is both groups bring good qualities to a project. The problem is both stop learning or maybe it would be better to say they value different learning.

Experienced software developers value what they already know or have experienced more than learning new ways to do things. They remember the problems they had but they do not always remember the exact context that caused them. This point of view will lead to several issues, for example:

• language lockin
• tool/framework lockin
• dogmatic opinions that do not explain context
• closed to new ideas
• afraid of change in general

Less experienced developers value new tools, languages, frameworks, etc. more than the lessons learned from experience. They have not had years of supporting an application and/or have only experienced a limited number of context. This point of view also leads to several issues, for example:

• so many languages in an environment it is difficult to maintain
• multiple frameworks in the same application
• I did it this way because I like it regardless of how it affects others
• no standards at all
• the language/framework allows it so I should be able to do it

The recent JavaScript semicolon debate is a partial example of both sides of these negatives of experience and lack of experience with very little benefit that both sides offer. https://github.com/twitter/bootstrap/issues/3057

The developers working on things like node.js, npm and the supporting tools have really pushed some really great ideas, tools and techniques in JavaScript. This is a very good thing! But you can see their inexperience in some of their comments. They will have a nightmare to support in the future. It reminds me of some of the young and upcoming Ruby/Rails developers 10 years ago. Go read what they are saying about having to support applications where they did not learn from past good development practices.

Experienced developers also had issues. The way they made comments drove some of the less experienced developers to get stuck in their point of view because the response was so dogmatic and contextless at time. This is sad because they have really good reasoning behind their points and if the advice was heeded some really painful issues could be avoided in the future.

It seems every new language or tool has been declared not ready for production by some experienced and respected developer, Visual Basic, Java, Ruby, JavaScript, etc. Then along comes a creative individual, who does not have the experience that says it cannot be done, and does something that solves real peoples needs. But unfortunately this creative person repeats some mistakes of the past and after 10 years of maintain these projects is afraid to change and repeat those mistakes again and the cycle continues.

Somehow we need to value of both learning from experience and openness to new ideas, languages, etc. The two learnings complement each other. Luckily if you muddle through that JavaScript argument you will see both young new developers and experienced developers commenting and writing blog posts

Agile is Festivus All Year Long

In agile we celebrate Festivus all year long, in an iterative type of way.

Festivus pole does not exist in Agile as it did not exist in the original O'Keefe family celebration. If you must have one use it to hold up your planning board.

Festivus dinner or Demo is a celebratory event where we look at the past iteration and rejoice in our accomplishments. Each group takes joy in that the fact that they alone made the iteration successful.

The Airing of Grievances or Retrospective is where we lash out at our team mates about how they have disappointed us during the past iteration or release. During this time we blame others for what did not go well during the iteration.

Feats of Strength or Iteration Planning and Backlog Grooming is where business an IT wrestle to control priorities and features that will be worked on during the iteration or release. Festivus is not over until the business lead is pinned down and forced to allow work on technical stories.

Festivus miracles or story acceptance are meant to occur throughout each iteration but regularly are delayed till the last day of the iteration or the first few days of the next iteration. These occur randomly at the point everyone is tired of arguing about one final UI tweak or refactoring.

Most Important Agile Team Role

My colleague and I were working on a training class for the agile product owner role and started discussing how important and difficult the role is. A good product owner needs to be able to communicate well with the business and the development team. They need to be able to take complex business requirements and break them down so the team can understand them. They need to make sure the team understands the context they fit in as well as help the team divide them in a way that is feasible from an implementation perspective and still delivers good business value. The also need to prioritize the stories or features considering ROI, usability, cost to develop and maintain and other considerations for different stakeholders. There is more they need to do. It is a complex and important role.

After discussing this role my colleague said this was the most important role on an agile team. I understand why he would say this because we have both seen many teams that struggle because they do not have someone who can perform the role. It is a difficult role to hire someone into because they need to be an expert in the field and trusted by so many people in the organization. The have to communicate on so many different levels, senior leaders, managers, business and technical.

Teams without a good product owner struggle with delays because they cannot get answers to problems. The build things that don't meet the business or customer's needs and they have a lot of rework.

I agree with my colleague that the role is important. But is it the most important role?

Assuming any role on a team is the most important is against the very basic principle that we deliver as a team. Actually a team could deliver without a specific person performing the role if others on the team had those skills even if they were shared among multiple people on the team. Would they be as efficient, no! But the could deliver and even deliver something good that meet the customer's needs.

Is it most important because it is difficult to hire for? The right person has to be found for this role and as I said earlier finding that person is difficult. Developers might be easier to find but I think this is because companies will hire anyone that has heard of java or .net as a developer. Hiring good developers is just as difficult and takes a lot of time. Difficulty in finding someone to fill the role just means more effort needs to be put into it not that is more important.

It seems to me there is no most important role on an agile team. The roles are all important in order to deliver quality software rapidly. To do this you need a team that understands how to break features down into small useful parts that are delivered often. This takes the whole team working together and being creative and working together to make sure all different aspects are thought about, developed, tested, verified and delivered. This takes a team with people that have great communications skills, development skills, testing skills and the desire and ability to work with others to push a project to completion.

However, that does not mean certain roles don't take more effort to fill. Finding a good product owner will take some effort so product or project leaders should start trying to fill this role early. This is just like any other risk management. A team does spikes or prototypes for high risk parts of the system, not because it is most important but because it is most risky. The same with the product owner role. This is a high risk role. It is important and hard to fill so start early to reduce the risk.

I think my colleague was confusing high risk with most important. There is no doubt in my mind if you wait until the development is starting to find a product owner you are going to be in trouble.

Thoughts?

Fix Ubuntu 10.10 Sony Vaio Sleep/Hibernate Issue

I have a new sony vaio F series and I have struggled to get the sleep and hibernate to work. I finally found a solution today at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/522998/comments/30.

Here is the solution copied from the above link.

create files : /etc/pm/config.d/00sleep_module and /etc/pm/config.d/unload_module
add line to files : SUSPEND_MODULES="xhci-hcd"

I hope this helps if you are having the issue too.

Google and Fraud

Free is good so I guess I cannot complain too much. I like my gmail accounts but beware there is not much protection and no easy way to recover if someone gets hold of your account. There is no number to call and get someone to lock an account that has been hacked. There is a form but filling it out says it could take 24 hours to verify.

Free always has a cost attached!

Here are some things to keep in a safe place.

1) The verification code that google sends to your secondary email address.

2) Know the date that you created the account, month and year. The recovery process seems to require this. I had to guess and of course my account is still locked.

3) Place a fraud alert on your accounts

4) Check your credit reports continually

5) Close the accounts that have or may have been tampered with or not opened by you

6) File a complaint with the FTC https://www.ftccomplaintassistant.gov/

7) I also filed a complaint with the internet crimes division of the government http://www.ic3.gov/crimeschemes.aspx

I will update this as I learn more.