WesWilliams

What Caused Your Success?

2016-09-15T10:26:00.000-07:00

Of course I know why I am successful, I am talented :-)

In the past few months I have been asked and/or told that I was not clear on what was the cause of my success(es), that is assuming I have actually had any.

Without being clear on what is the source of success, it is very difficult to duplicate it.

I have a hypothesis that most change initiatives and transformations fail for a very similar reason. We try to duplicate a success and it does not happen. We use the same methods, techniques, practices and patterns. We teach the same values and principles. Despite that, the results are less than impressive.

Of course I know why things didn't go well, it's those other people :-(

We have many reasons for these failures: lack of alignment of culture with new values or outcomes, stuck in their old ways of thinking, lack of knowledge or experience, lack of support at the right levels, unwillingness of those that need to change, mechanical following of the rules, lack of trust, not a safe learning environment, etc.

I have used almost all of these reasons, or to be fair excuses, for why things failed or at least didn't get to the level of success I hoped for. I am also clear that each of these reasons direct the cause of failure away from me.

An interesting observation is, I have seen success when each of those reasons existed. Somehow we found a way, despite those reasons, to do something awesome. Actually, I have not seen any situation where multiple or even many of these did not exist. That is why I am clear that they are just excuses. The fact is, I am not at the source of what enabled us to overcome these excuses in one context and not in another.

Surely, there is a way of operating that does not need to blame

I am on a journey to discover what it takes to cause a group of people to become a team and iterate towards success. That is, to take on something that they say is worth doing and overcome every excuse we have to achieve it. I do not think this will guarantee success. I hope it will reduce the excuses and blame for what happens.

Here are a few things I have observed about myself that likely can help me to have empathy for others. I bring a lot with me that is unlikely to lead to success. I have biases and thoughts that run through my head that I have trouble "getting rid of". These thoughts often sound like: they don't care, they don't get it, what !@#$%^&* idiots and worse. This might also sound like: if they would just do what I told them because I am the expert, I have done this in the past and it worked so you should too, everyone knows this is the best/right/proven/[insert other make wrong term here] way to do it. I can usually find a good justification for the thoughts in my head and they are still not likely to be very helpful.

I have also observed a few other thoughts, that frankly I listen to less often than those previous ones. They sound something like this: I know this person is not an idiot so what do they see that would cause them to view the situation so differently, I wonder what they know that I do not, I wonder if they have had an experience that I have not or why is that causing me to react so strongly.

Based on my experience with my own thoughts, one of the first things to deal with is the first set of thoughts, which are the ones I tend to act on. How many of the normal failure reasons can be attributed to those thoughts and the reactions they generate? If people in a group come with those thoughts what is the likelihood we will have the actions that we associate with alignment, trust, safety, support, discovery, new options for how and what we do? Since we likely all come with those types of thoughts, what will cause us to put those aside, as many times as necessary, in order to create space for a group to act together towards a goal?

When I cannot or do not even try to get clear on where the other person is operating from I have only one option left to me, convince them to agree with me (see previous post on agreements), or put another way, use force to convince people I am right and they are wrong.

Ugh! Surely, there is a better way.

Another aspect is the ability to be responsible and accountable for what happens without blaming. Success or failure will have consequences. This seems to be the reality we live in and it is not easy to cope with.

So they journey continues...

Working Agreements

2015-04-30T11:48:00.002-07:00

Working Agreements

In a recent post, making a distinction between agreement and alignment, I discussed helping two groups of teams develop a partnership. One valuable discovery was watching how working agreements developed.

Starting with an Intention

We started with an intention not a set of working agreements. The intention was created based on what the group was out to achieve.

The intention was, with names removed, "Team Blue requires Team Green in order to achieve it's desired outcomes. Team Blue will groom the backlog to a level that Team Green can say they are ready to be planned." This was done in the context of developing a partnership.

Discovery of working agreements and rules that support the intention

Working agreements were discovered by doing the work and a common intention.

We discovered how often we needed to meet and for how long. We discovered how best to track where we were and how to make that visible. No one had to be convinced to use the tools or follow the agreements, it would have been silliness not to.

We discovered what topics and discussions lead us away from our goal, and rules were setup regarding those topics.

Acts of Leadership will cause working agreements

"Teams develop norms whether they are paying attention to norms or not." Esther Derby - See more at.

It was acts of leadership that injected the possibility of a future of partnership and participation. From this created possible future came working agreements that supported that possible future.

A common practice I observe is getting people together to create working agreements. This is done without creating a future, an intention, that resonates with people. The outcome of this is a set of agreements that we use to make excuses for not keeping them.

Leadership injects what is missing that creates space for people to win. In this example, leadership injects partnership and removes anything that is not partnership.

Leadership removes what exists that will hinder people from winning, by helping them see what is in the way of them winning, in this case blame, disappointment, broken promises, lack of concern for others and more. Much of this was displaced by injecting partnership.

A leader helps people see their normal way of being and acting that is taking them where they say they do not want to go.

A leader develops people to have the compassion to develop others such that they see and deal with their inconsistent actions, as the leader sees and deals with their own inconsistent actions. From this real working agreements can develop and evolve.

Effective working agreements are not a team goal they are an outcome of being team.

Alignment vs Agreement

2015-04-27T10:03:00.002-07:00

a·gree

əˈɡrē/

verb

verb: agree; 3rd person present: agrees; past tense: agreed; past participle: agreed; gerund or present participle: agreeing

1.
have the same opinion about something; concur.
- approve of (something) with regard to its moral correctness.
  "I'm not sure I agree with abortion"
2.
consent to do something that has been suggested by another person.

a·lign

əˈlīn/

verb

verb: align; 3rd person present: aligns; past tense: aligned; past participle: aligned; gerund or present participle: aligning

1.
place or arrange (things) in a straight line.
"gently brush the surface to align the fibers"
synonyms: line up, put in order, put in rows/columns, straighten, place, position, situate, set, range
"the desks are aligned in straight rows"
- put (things) into correct or appropriate relative positions.
  "the fan blades are carefully aligned"
- lie in a straight line, or in correct relative positions

Agreement is less helpful than we think

Agreeing and blaming

I have been pairing with another coach, in a high dependency environment, to help create a team phenomenon, a partnership, within a team of teams. A phenomenon we have observed is the how the need for agreement tends to slow conversation and cause partnership to deteriorate.

The initial place the teams operated from was trying to get the other team(s) to agree with them. These conversations were quite painful and not very productive. Trying to get agreement was leading to one group trying to convince the another group that their view was the right view.

Dissonance

dis·so·nance

ˈdisənəns/

noun

MUSIC

noun: dissonance; plural noun: dissonances

lack of harmony among musical notes.
"an unusual degree of dissonance for such choral styles"
- a tension or clash resulting from the combination of two disharmonious or unsuitable elements.

Outcomes of agreements tend to be contract like. I will give you X if you give me Y with these caveats. There are plenty of outs if one side did not meet the contract exactly. There is no commitment.

Agreement tends to bring a dissonance, in the conversation, when their are break downs. When break downs occur, i.e. people's intentions are being thwarted, one group is trying to "fix" the other group. The discussion sounds like "it should not be this way" or "it should be this way". As a group they are unable to deal with what is happening. Instead on an inquiry into what is happening, blame and excuse exists.

Alignment is an interesting distinction to agreement

Alignment and committing

As we introduced the idea of partnership and listening for what it takes to meet another teams concerns, agreement started to disappear. Teams would have discussions that started with what do you need to know to be ready to do this. It started with an inquiry into the feature. The inquiry would then go back and forth. Often a team member would take information from one team and start walking through the steps it implied and finally just stop and go, "ahh I get it".

Resonance

res·o·nance

ˈrezənəns/

noun

noun: resonance; plural noun: resonances

1.
the quality in a sound of being deep, full, and reverberating.
"the resonance of his voice"
- the ability to evoke or suggest images, memories, and emotions.

Alignment looks like resonance, deep, full and reverberating. All concerns are out and everyone is clear the direction we are headed will fully deal with them. The attitude is, we can make this happen and it leaves space for an authentic commitment, despite any complexities.

Teams in this stage trend away from excuses and blame when things do not go as expected. Teams at this stage understand that breakdowns will happen and they can look at what is happening and where they are intending to go and deal with the break down versus blame someone for it.

Give it a try

Why not try coming to alignment instead of getting agreement the next time you need to work with someone.

Instead of trying to convince them to agree with you, inquire into what their concerns are. Listen and look for possibilities to deal with those concerns. When all parties concerns are on the table and it is clear everyone is committed to meeting those concerns, observe what happens to the conversation.

Notice your own ability to deal with others concerns. Can you be with them and deal with them or do you simply explain why they are wrong?

As with all inquiry, you will learn more about yourself than anything else.

Agile Process Coach, Really?

2015-04-23T10:04:00.003-07:00

Really?

Agile is not a process... Here's an Agile Process Coach to help you understand that. :-)

It shocked me the first time I heard that title.

Of course, when I am honest with myself, I know that I fallback to being a process consultant instead of a coach when I hit certain impediments.

Tools and Techniques are Process Consulting

I am seeing way to much of agile IS:

Doing 1.5 hour retrospectives using the 5 stages as defined in the book by so and so.

Stories are written in the format in that book by that other Scrum dignitary.

The ideal team size is...

The ideal planning cycle is...

The best tool for this practice is...

blah, blah, blah...

There is nothing wrong with these things. These are tools and techniques, often good ones, and they are not agile.

They do not generically combine, without context, into an agile process.

The Easy Way

The easy and minimally effective way is to use this tool, technique or process.

Do it this way and it will solve all of your problems.

Standup is asking these 3 questions.

Here is the correct tool, technique and/or process.

You must use Scrum or Kanban or XP or or or

I have the answers for you.

Making people bad and wrong.

If you do not use so and so's 5 steps for retrospective you are doing it wrong.

Defining the right process outside of doing the work as if there is a generic context.

Release planning IS all of the stories organized by team and by sprint for the next n Sprints.

There is nothing wrong with these things, they may be helpful at times. These things are process consulting, not coaching and not agile.

The Hard Way

There is a more powerful way based on being compassionate, inquiring, being curios, discovering and being generous. You might call this leadership.

This is hard and it will require uncertainty and fear to be dealt with.

Getting comfortable with what is happening.

Getting comfortable with entering into an inquiry with curiosity and learning.

Developing our ability to discover and uncover better ways of working by doing and helping other do.

Discovering what people are committed to. What are they out create or do?

Helping them see when their level of performance in achieving the things, they say, they are committed to, versus measuring how agile they are, or how well they follow the defined process.

These things are not more right than the easy way. They are more powerful at allowing people to uncover and discover for themselves who they are and what they are out to create.

These things will enable people to become profoundly aware of what they say and what they actually do.

A coach will do this with compassion remembering what they had to discover.

A coach will be someone who remembers how painful it was for them to admit, to themselves, that they say one thing and do another.

A coach will remember how often they judge people on a standard they do not follow.

Where am I

I know I struggle with going back to the easy way.

To often, I encounter a situation where I sell out.

I turn back to being nice outwardly and thinking inwardly how bad and wrong you are.

When I see that in me, I simply acknowledge and get back up and go again... Often with help of my own coaches.

Where are you?

Manifesto for Blame Driven Development

2015-04-21T09:27:00.001-07:00

Manifesto for Blame Driven Development

Performance Improvement Plans and Firing People over Resources and Interactions

Bug Triaging over Working Software

Personal Agendas over Customer Collaboration

Endless Debates over Responding to Change

That is, while the items on the right will give us a chance to succeed,

we value covering our ass over a possibility to do something meaningful.

------------------------

Principles behind the Blame Manifesto

Our highest priority is to deflect blame for all problems

through early and continuous failure of others.

Welcome changing requirements, even late in

development. Blame processes harness change

for opportunity to delay commitments.

Deliver non-working software infrequently, from a

couple of quarters to a couple of years, with a

preference to the longer timescale or not at all.

Business people and developers must make

vague and incomplete requests of each other

daily throughout the project.

Build projects around depressed resources.

Give them judgement and punishment,

and watch them squirm.

The most efficient and effective method of

conveying information to and within a development

team is domination and intimidation.

A high bug count is the primary measure of progress.

Blame processes promote sustainable employment.

The sponsors, developers and users should be able

to maintain employment for an indefinite period

regardless of their inability to honor commitments.

Continuous attention to technical incompetence

and poor design enhances blame-ability.

Simplemindedness — the art of maximizing the amount

of useless conversations—is essential.

The best straw men architectures, incomplete requirements and aimless design

emerge from withholding information.

At regular intervals, the team reflects on who

needs fixing, then tunes and adjusts this person’s

behavior.

------------------------

Here is a blog post with an example of implementing Blame Driven Development.

Accomplishment and Satisfaction Over Happiness

2015-01-10T12:52:00.000-08:00

“Great things are done when men and mountains meet.”
― William Blake

“You may not control all the events that happen to you, but you can decide not to be reduced by them.”
― Maya Angelou

The Challenge Accepted

Wow! No one had asked me about that tool in over a year. I was sure that no one was using it anymore, I thought to myself as I read the request to review a set of changes and update requests. A bit excited that something I had created was still interesting to others; I decided to take on the work of reviewing changes and updating the tool.

I was satisfied with the tool after I created it. Over time, my skills and the available tools have improved and the code looked very inadequate. That is me trying to be easy on myself. Of course, the inadequate area of the code happened to be the area I needed to update due to a deprecated API.

Continuing despite how I felt

It took me a day to recreate my desire to update the code after looking at it and feeling frustrated about it's state. I was definitely not happy!

Once I started working on the code, I was sure things would get better quickly and I would have it back to a state that made me smile. Nope! After an hour of working, I had completely obfuscated the code. So, I reverted it back to the original state to get the test working again. At this point I was feeling angry with myself and I definitely was not feeling happy!

This unhappy state was not due to an oppressive working environment. It was not due to anyone around me not doing their job and dumping all the hard stuff on me. It wasn't even due to terrible, buggy code, this code only had one defect reported by users and that was for a test case that did not exist when I released it. It was simply the emotions I felt as I went through relearning and dealing with the state of something that was not easy to deal with, mostly due to time.

Accomplishment and Satisfaction

The next day, I set all of those feelings aside and worked on updating the code. The first I noticed was there were things I did not need. The code that needed updating came from someone who required features I did not need so I deleted those parts. That made it much easier to deal with and understand.

The person who asked for the update sent me a link to a document that described updating from the old style to the new style and this turned out to be simple with the unused parts removed. After a couple of hours I was done and all the old tests still passed. I accomplished what I set out to accomplish and it was satisfying. I was happy for a while, as well.

Wes, why do you write this simple story?

It was been relatively popular of late to recommend people measure happiness to see how well teams and people are performing, especially in the agile community. It generally works by asking question like the following:

How happy are you? (on a scale from 1 “very unhappy” to 5 “very happy”)
What makes you feel best right now?
What makes you feel worst right now?
What would increase your happiness?

NOTE: The implementation of the happiness index at Crisp had very specific intentions and a better wording than the generic one about. e.g. How happy are you with Crisp? vs. How happy are you? Though still using the idea of happiness, they also state in the blog post that "The important thing is not really the content of the A3 sheets. The important thing is how they were created, how they are used, and the fact that we now have an explicitly defined identity & strategy, which makes it easier to criticize and iteratively improve over time."

I have strived for happiness, and still do at times and seeking happiness in and of itself is never satisfying. If happiness was what I really wanted, I would not take on many challenges. The example I gave is quite a simple one that involved a few hours over 2 days. In other words, it does not compare to most of the bigger challenges in life I take on.

The intention people seem to have with the happiness index or metric is not my concern. The intent is usually related to creating an environment where people can achieve mastery, autonomy and purpose.

I have the same concern for an environment that allows people to achieve mastery, autonomy and purpose. In my experience happiness does not represent those achievements. This could be a simple definition problem for many using the term. e.g. languages other that english tend to have a broader selection of words that are incorrectly translated to happiness. The first meaning of happiness, from Merriam-Webster is:

hap·py

adjective \ˈha-pē\

: feeling pleasure and enjoyment because of your life, situation, etc.

: showing or causing feelings of pleasure and enjoyment

: pleased or glad about a particular situation, event, etc.

Maybe others are different than me, but my feelings, i.e. emotional states or reactions, change throughout the day and usually minute by minute. These feeling are always with me and often affect my actions, yet they do not tend to cause actions that lead to outcomes that move me towards mastery, autonomy, purpose, accomplishment or satisfaction.

In my experience, my feelings often lead me in quite the opposite direction of my intentions. They lead me to stop taking on challenges. They lead me to not do things I thoroughly enjoy. I get to the end of the day and I question why I wasted so much time, feeling sorry for myself, watching TV or reading social media, instead of playing the ukulele, writing down what I have learned today or creating something that solves a problem I saw.

I am not trying to call happiness, and my other feelings, good or bad, that is a bit irrelevant as they are always with me and I must deal with them. I am saying these are not the things to measure.

In order to keep happiness high or more likely return it to some 'acceptable' level, I will need to constantly input some type of stimulus.

I propose we replace the happiness goal with goals for:

Accomplishment: to achieve what we set out to achieve.

and

Satisfaction: fulfillment of our intentions

As with those experimenting with the happiness index, I am aware that these in and of themselves are not complete. I can easily see someone with destructive intentions using these incorrectly. The very definition leaves room for people to 'fail' because they do not define what we are out to achieve nor what our intentions are.

In my experience, the possibility of failure is required for me to achieve those deeper intentions beyond my own happiness.

I have shared some of my experiences and I do not ask you to apply this to yourself. What would be much more interesting would be for you to look at your own experiences, which will differ from mine, and answer the questions:

Is happiness what helps you verify that you are heading towards your intentions or purpose?

Do accomplishment and/or satisfaction come closer to allowing you to adjust your path towards your intention and purpose?

Maybe there is something else?

Shu-Ha-Ri Applied

2014-03-09T22:44:00.003-07:00

Shu-Ha-Ri Applied

edited: 2014-03-10 - grammar issues

The Issue

Shu-Ha-Ri and the Dreyfus model are very helpful tools I have used to help understand the point of view of a person I am working with and guide me in how I coach them. I am seeing a use of these models that concerns me and appears to hurt our ability to change more than help. These models are quite helpful at the individual level for a specific skill. Shu-Ha-Ri seems to always be described, in its initial context, as a relationship between teacher and student. Applying it beyond that without potentially significant changes appears to be an abuse of the model.

I intend this article for experienced coaches, change agents and change organizations and think that other individuals and groups with a global, enterprise or other large scope will find benefit in thinking about this subject. This article is focused on when these models are applied to a software organization moving towards Agile and Lean.

More background

Articles, such as this one by Rachel Davies have implied the models are wrong to apply for forcing someone to do agile practices. I tend to agree with Rachel on this issue and would like to expand on where I see the problem. The biggest issue I seen is when applied in a larger scope of people, team or organization, they seem to be misleading and guide us to treat knowledgeable people as overall beginners. The danger here should be obvious, smart people treated as beginners will be put off at best and likely fight against us.

Interestingly, when I read Alistair Cockburn's article, where he introduced Shu-Ha-Ri, he applied this to training courses. These can be targeted at individuals at a specific level. Books and articles as well can easily target and let people know who the intended audience is. Many people have no problem reading beginner material or attending a introduction class to start understanding a new skill or topic. These are all targeted usages of the models that allow the individual to choose to be a part of.

Jeff Sutherland also uses shu-ha-ri in guiding Scrum implementations. Notice that this is also a shu targeted at the Scrum Master. In the shu state, the ScrumMaster sets up the process, helps the team get to a sustainable pace with known velocity and uses the

Retrospective to introduce change that improves velocity. I disagree with the velocity target but I will use it as an example goal. In this description the scrum master is looking at the team, though the article seems to mix abstraction levels between Scrum Master level and team level. Sutherland could have said the Scrum Master doesn't allow them to vary the process but he does not. He does not say the Scrum Master tells the team to do practice X. Instead the Scrum Master guides towards achieving goal Y via retrospection. He might recommend a practice to help achieve goal Y if the whole team cannot identify a possible practice to improve the current situation but the Scrum Master does not dictate the practice.

Looking for guidance in helping an organization change

I think Sutherland starts to imply a difference in applying the shu-ha-ri idea in a larger context beyond the individual, we target goals and outcomes to a less mature group and guide them towards that. This is not the same as you do exactly the one practice taught by the teacher. I believe it is a bit more than simply a goal. I like the way Don Reinertsen states a similar idea, "decentralized control with decision rules". See the video LSSC12 : Decentralizing Control: How Aligned Initiative Conquers …

Based on my experience organizations fight back against the absolute one way given by a enterprise or global level group. They often do so with the right intention. The group fighting back knows their context and see weaknesses in the one practice for beginners. Having the organization work at the shu level as a directive is where we lose supporters. We are not talking about people new to software development, shu in Aikido is someone completely new. It is a rare circumstance that we are talking about people that have not delivered software in the past. Agile and Lean are not the goals or at least should not be. They are mechanisms to help us think about the situation and see it more clearly. If we are guiding a team or organization we should be guiding them towards the goal. Let's assume for example, in the rest of this post, that the goal is delivering value more often to our customers and other stakeholders.

What does team level maturity look like

I think I have jumped a bit far ahead and assumed we are ok with the idea that there are no shu level teams and organizations where the teacher gives them the one rule, way or practice to follow. So let's back up and look at what is implied by a team or organization being shu level at their primary tasks.

If the shu fits we are in big trouble

Maybe a shu level team is one that all members are at the shu level. Can they be at the shu level for their primary tasks of delivering software? Maybe, but this would be for such a short stage that by the time someone is invited in to help they have already left the shu state. If they stay at this state for any time at all they will no longer exist because the organization, product or team would fail in a way to bring a drastic change to the team or it would cease to exist. This seems like such a bad state to be in that it would be rare and could not last long. We really should not assume all teams are at this level and dictating the one way is not likely to fix this team. The team has to be changed in a more drastic way.

This state does not match my experiences. I have seen a team that really could not deliver but the organization caught this mistake relatively quickly and fixed the problem. I say team but it was an organizational problem where people were hiding the real state to protect themselves and it failed relatively quickly. In this state, they also did not ask for help. It was not until they had failed and realized the problem that they asked for help. They also realized most of their issues and it was clear they were not a shu team. When they admitted the failure the true level of people who were being silenced by the system came out and they new how to fix their issues with very minimal encouragement and guidance.

Maybe a shu level team is a team where all team members are at the shu level for a specific new practice. Would that make them a shu level team? Meaning, a team which we treat as beginners because they do not know a practice we believe would make them more effective. I am thinking of practices like TDD and Uncle Bob's idea of a foreman. My experience matches more with Jason Gorman's. It just will not work to impose these practices. In my experience teams will meet any metric you impose to verify it and will actually make themselves even less effective. If we want to call them a shu level team we will have very little success. I am proposing they are not a shu level team. They are likely far from a Ri level team but they are not shu. They have some experience and success at delivering software and we do damage by treating them as beginners. They are likely shu at TDD and they likely need to be challenged to improve their capability to deliver. In my opinion, this is different than being a shu level team.

Maybe a shu level team is a team with so few ri/ha team members that they cannot successfully guide the shu level members and keep them from doing more harm than good. This seems more likely than the first example of all shu level members. This team actually has an advantage and solves the problem faster than the mythical all shu members team above. The few ri/ha team members make this visible quickly out of fear of their own failure if nothing else. I have seen this team get the problem fixed relatively quickly.

For me the real issue is having a shu level team or organization is never what we need to solve. That shu level team or organization gets eaten alive by the market, internal or external, or they fix the beginner problem so quickly that we would never be asked to come in and help. If you think your organization is at the shu level ask a few questions about it. Do people know where they, the team or organization, is not very effective, at least in some areas? So far I have not seen any organization where people could not answer this question to some degree. Enough people to know that change was necessary at a minimum. All of these organizations are currently delivering software. I would put them at the compotent state in the Dreyfus model at least. They need and benefit from someone looking at what they are doing and reminding them of the goals. The need and benefit from someone pointing them to solutions they have not tried and influencing them to think about them. The need and benefit from someone guiding them in practices they do not have experience implementing. They usually need to choose those practices based on the goal discussion first.

At this point I may not have convinced you that shu level organizations and teams are not who we are asked to work with. If I have not convinced you; then please keep testing to see if the one way is causing more good than bad and is change truly sticking.

Ha!

If I have at least convinced you that it is possible there are no important shu level teams and organizations, or at least you are not working with or for one, let's continue. Ri level organizations and teams are probably very rare and frankly unimportant. If you are competing against one you will not likely be in business long, unless of course you have the cash to buy them in which case you probably should. So let's not even worry about that.

Most of teams and organizations are at the ha level or Competent level. These are the ones that see the need for improvement. They likely have asked you to help them by using Scrum, Kanban, Lean, XP or some other change to make the more effective. Likely, they have even asked you to teach the one true way. There are ha level organizations it seems to me. Interestingly, they often even state in contradiction to their request to you, to teach

the one way and be consistent across all teams in the organization, that they do not want be prescriptive. What would lead them to say this? Maybe it is the fact that they see multiple activities and in many cases teams and groups with a poor vision of the goals behaving in a way that they want to put structure on. They often see that being prescriptive is not likely to work and yet they ask for it anyway. They have not seen how to achieve similar goals in different ways while dealing with conflicts between groups that deliver together. These are ha level teams and organizations that need to be aligned to a goal before any of these ways will make sense. Once they have that, then they can be guided to practices and may even be willing to try a practice they are at a shu level to see if it helps.

We, as coaches and change agents, need to help them understand the goal and make that clear from top to bottom. Once we do that we can help them see with some minimal guidelines where they could improve to meet the goal. They will also see when they have a goal that is different and start pushing back on the system that is giving conflicting goals. Interestingly, until they see this conflict teams and organizations do not push back openly in a way that can get the conflict resolved. It is usually not politically safe to do so. They push back in a politically safe way that continues towards their conflicting goal while meeting a metric, in number but not value, that is meant to show direction towards a goal they are not trying to achieve.

When we start treating people like they are successful and knowledgeable, by asking their input on how to achieve the goal, we will find a better way to achieve these goals. We will often be asked how can that be done and give us the opportunity to introduce a new practice that helps them. They are more likely to be open to the new idea sooner if they have asked for help achieving the goal. They are more likely to spend the effort it takes to learn the practice than simply fake the metric. They are even likely to help choose a metric that helps them determine if they are getting better. The first XP team I worked on was this way. We had the opportunity to try something and we started seeking ways to do it even better. We learned metrics that helped guide us. We started to understand weaknesses and strengths of our own metrics. Teams that were forced to do the XP practices did not get the same benefits. Their builds were often broken, their test coverage went up in unimportant areas but met the targets.

Most organizations will not allow Uncle Bob's foreman to control the code, it would have appeared significantly slower. They are still a ha level organization hiring more and more developers to fix a problem more developers will make worse. However, it probably would require a foreman to check everything in this forced 'treat the team as shu level' environment. Treating the team and organization as though they are a ha level team and they will start to see the trusts and reciprocate by helping the organization see the problems and find practices that help improve them.

Summing it up

When a team or organization has experience at their primary tasks it is wrong and dangerous to treat them as beginners. It is wrong because they are not. They need some time to choose the practice that moves them closer to a goal and learn that practice they are beginner at. They also need to see the goal in the bigger context.

I really doubt you are working with or for a shu level organization or team. Is it possible, that we as change agents and organizations, due to our own level of HAness, are treating teams and organizations as if they are shu when they are not? Should we make sure we

are not teaching the one way because it is easier than dealing with people and helping them understand the goal? I know I need to think about this more often based on my past mistakes.

As always, I am seeking your feedback more than agreement. Please leave your comments and help me improve.

Who gets value

2014-02-07T11:23:00.002-08:00

I was in a discussion earlier this week about user stories and one of my colleagues states that 'as a' was about the actor and I had an immediate allergic reaction to that statement. 'As a' should point to who is getting value no matter who or if they are anyone else is performing a specific action. As a user of many products, way to many organizations think I am actually interested in entering data or performing some action and have not thought about my need.

Give me something for nothing

Let me start with an example.

In order to respond quickly to my friendsAs a Facebook userI want to be notified when someone comments on my status

This story is hoping to benefit the person whose status is being commented on. The person acting in this case is a friend leaving a comment. The person getting value did not have to take an action to get this value.

However, what if it is not what they wanted...

I don't want to use your form or enter data

Sometimes getting value does require the user to take some action. Most of the time the user does not want to act or wants to do as little as possible to get the value. Let me give another example on the same situation.

In order to avoid silly interruptionsAs a Facebook userI do not want notifications from certain people

In this case it is likely that this user will need to take action. Actions is not what they want however, it rarely is. They want to avoid getting certain notifications.

Challenge

It is my experience that focusing on the actor often leads to solving the wrong problem or solving the problem in a poor way. Reminder: The user rarely wants to enter data.

How many of your stories are thinking about the actor? Try rewriting your story to think about who the primary beneficiary is and see if that leads to a better solution.

It is also value not format

The format we are talking about is not very important. The important thing is are we thinking about who gets value, whose problem are we solving and are we solving it in a way that is simple and straight forward.

Starting with Teams Requires Fixing the System

2014-01-26T19:44:00.001-08:00

Being a part of Agile transformations since 2001 I have listened to and participated in several discussions about teams vs system changes. However, I am not sure these two things in and of themselves are different. If you start with teams, as most Scrum and XP transformations do, it is a system change in many organizations. Teams don't just magically happen because you put people together and tell them to self organize many changes to the system must take place.

Teams that stay together will be an early system change for an agile development environment to succeed. Quite often, this means financing has to change. Financing happens for projects and long term teams that last for the lifetime of a product or service is a system change that is likely to be met with resistance. Budgets are made to support x number of people for y number of months to deliver scope z. An organization must ask how is it going to maintain that software? How are we going to adapt that software to changing needs of it's customers? Who is likely to be most effective at maintaining that software, those who created or the junior maintenance team?

Teams that are cross functional are required in order to complete work every two weeks or less and is likely to run into several system issues. Teams in many organizations are dependent on design decisions from people outside the team, such as technical leads and architects in a global architecture team. Their ability to make decisions are slowed by late reviews and feedback leading to incomplete work each iteration. Teams in many organizations rely on a long lists of specialists such as architects, technical leads, database specialists and official build and deployments teams just to lists a few. The system will have to change to allow the team to do builds at will and deploy them to different environments. An organization will need to trust teams to build the software in a consistent manner? They will need to overcome the resistance of those teams currently doing that effort trying to protect the perceived loss of responsibility and the fear of losing their jobs. They will need to solve the problem of global architecture concerns and shared direction among teams that deploy into common environments while allowing the team to learn and adjust to the needs of the customer. All very difficult system changes.

After cross functional team are created it becomes clear that further improvement will require reducing the frequency that specialists are needed. This will again require a system change that requires overcoming fear of losing control and influence from those specialists. The benefits are good for everyone as each person gains a broader set of skill the organization becomes more agile. However, this apparent loss of control and influence is difficult to overcome in most organizations.

Teams that are focused on value versus projects focused on fixed budget and scope is another system change that is required in many organizations. Traditional systems are setup to expect a fixed budget and scope setup in advance. Agile says fix the teams and the budget and adjusts the scope to adapt to current needs and learning. The system will fight against and undermine the team making good decisions if it is not changed. An organization must honestly ask itself, with my fixed budget and scope projects in the past, did I get the things I wanted, needed or even originally planned? If not why? How long did we spend in discovery and analysis? When did we learn the most information that disagreed with our original assumptions? What do we do that really does have a fixed dates, such as compliance requirements, and how much of our work consists of these true fixed dates? Is software changes the only way to meet those fixed dates? This type of openness and honesty is also a system change in most organizations.

Teams that deliver as often as possible versus those who hand over testing at the end with n cycles of bug fixes is also a system change. Most organizations do not believe it is possible to deliver quality software quickly. Their experience likely backs up the assumption that software is very buggy early on. They may never have experienced a team that is focused on high quality rapid delivery, a team that is automating most or all normal checks of the system freeing time to dig deeper into possible limits of the system, a team that is collaborating so closely that all parts of the organization know what is being delivered and understand each direction change. They have experienced miscommunication, lack of trust and finger pointing between product, project management, development, testing, marketing and sales to look for who is to blame for the latest failed project. My experience says this trust is very difficult to overcome and will hinder teams until they can get quite a few wins under them. Wins that the system is, unintentionally, fighting against.

Teams are a system change in most organizations. Teams are not an evolutionary system change that you get in a Kanban environment, instead they are a chosen from the beginning system change that will bring fear and disruption. Don't fool yourself that you can start with teams and wait on system changes later. Creating teams will point out and magnify each of the systemic issues before teams become effective at delivering quality software. Start dealing with these issues before you create teams or you will likely lose many of the people who have the most knowledge and experience about the system and can help you fix those issues.

Formative Organizations - Introduction

2013-10-26T01:03:00.002-07:00

Update: removed Deming comment that was out of context.

Formative Organizations

Building a Foundation on Integrity, Delivery and Learning

The Problem

There are many articles, like this one in Forbes, talking about the life of organizations becoming shorter in one dimension or another. Does this idea of creative destruction have to be outside an organization? How might we increase our organizations likelihood of adapt to an unknown future? It seems like a worth while

The Direction

We are taking this idea of flexible foundations and starting to build user interfaces that are not bound to what we know today. That is, we are not designing to only handle resolutions and browsers that exist now but to scale, both up and down in size and capability, as they change. We are starting to create distributed architectures that can take advantage of cloud computing to grow and shrink our infrastructure to meet changing needs. Our organizations, however, are stuck in a rigid unbending system that hinders us from adapting, growing and developing to meet the fast changing market we are in.

I don’t think this requires a great new framework to scale Lean or Agile. As Arlo Belshee, @arlobelshee, tweeted recently, “These days I wouldn't say don't scale. I'd say make shipping easy, then solve the few remaining problems.” We don’t need to scale agile, we need to make our organizations scale. However, let's not fool ourselves that the solution is simply a technical one. The solution starts with people! We can use frameworks but we should be very careful with them and not bind ourselves and our thinking to them. Tight coupling to frameworks makes code difficult to change. Tight coupling to agile frameworks makes organizations difficult to change.

After starting the book Lean Solutions, I have not completed it yet, I also think Arlo has stated an incomplete view of the problem. It is not simply shipping, though shipping is clearly the early part of the value chain, it is a full circle of customer need or want, known or unknown, possible solution by someone, learning and supporting the customer and other 'stakeholders' and continuing to solve the changing needs in the future. Supporting this full cycle is what I would like to be apart of refining.

The Formative Organization Idea

Set a vision and create a goal to deliver that vision fast with integrity, learning and adaptability.

Merriam-Webster gives the second meaning of formative as an adjective as:

“capable of alteration by growth and development; also : producing new cells and tissues” Merriam-Webster

The basic idea is creating the ability to grow and improve leading to new ideas and solutions that improve and/or replace the existing ones. To do this I think we can combine several sets of overlapping principles and practices that allow an organization to give people the view they need to adjust what they are doing to support this full cycle. Obviously, my idea is not completely unique and dreamed up by me, not even a significant portion of it.

The primary source of principles and practices for creating Formative Organizations

The Antimatter Principle - "Attend to folks' needs." Bob Marshall, @flowchainsensei
Lean Startup - Eric Ries
Continuous Delivery - Jez Humble, David Farley
DevOps - Gene Kim, Kevin Behr, George Spafford

Combining these principles and practices appear to start us heading down a path towards a more complete system view. A view of this cycle often referred to as creative destruction.

I am not sure the implementation of these ideas have fully dealt with all areas though I think the principles might. They clearly show how we bring together customers, idea people, delivery people, support and operations people and a few of the roles like risk and compliance. The idea of a formative organization must bring all roles together to understand the current vision and goals and knowing when that vision and goal should change.

Integrity

I put the Antimatter principle first on the list of guiding principles to indicate the importance of people. This idea that we all must think about others and how we affect others and work together to move that positive for everyone. I think the agile idea of cross functional teams is headed in the right direction. Many implementations are limited in application. All people must be involved and have their needs considered.

Delivery

Many agile teams limit the idea of cross functional teams to business, development and testing. Though small teams need time to focus, a real need, quite often others need to be involved often. I think that the other 3 sources of principles support this idea of broadening the basic agile cross functional team to include all value adding people; business, customer, development, facilities, finance, HR, operations, testing, etc.

This may be more of a group than a team if you use size to determine the idea of team but somehow this larger cross functional organization of people are required to meet that full cycle and each must know and learn how they effect the others.

Learning and Adaptability

Learning must happen along several different paths. The first is understanding how we all fit together and affect each other. It is a focus on how we move a vision and goal forward and allow it to change as needs change and as abilities to meet those needs grow. If we do not have this down all other learning is likely to hurt us more than it helps us.

Once we know how we affect others we can continue to learn how we deliver as often as possible. Of course the primary goal of having the ability to deliver often is continued learning about how we affect others. Specialized skill learning is very valuable and a must if we are going to deliver our solutions often. We must remember that most of the specialized skill training information we use to learn from does not take into consideration our primary learning of how we affect others. Part of specialized learning is learning how to apply it in a beneficial way. This is almost always adaptive in nature. This adaptive process depends on the integrity side. We must be transparent about what we know, what we project is likely with this new learning and what we have no idea about.

This process of continuous learning is the driver of continuous improvement. It is also the driver of vision and goal changes. As we all learn we start to see a better future together and adapt to that future.

Conclusion

Early on I mentioned a single vision and goal but I do think the larger an organization gets the more uselessly generic that is likely to become. It is likely multiple cross functional groups are will develop. This may be simply changing the structure of silos versus removing them. Frankly, I'm not sure if this is good, bad, indifferent, more risky or less risky but it is the direction I am exploring.

Each of the sources of principles I have listed are people focused. It seems this cannot be said and strived for enough. We must be realistic that this is the hardest part. It is easier to focus on process, methods and practices and likely always will be. I just have trouble seeing how a process that is not focused and understanding peoples needs is likely to meet them.

I have some hope that this is more than just a bigger idea of cross functional teams and self-organization but I also have some doubts about that. I am theorizing that if we can have a broader focused set of people we can increase our ability to alter and develop our organizations that creates new cells faster than old ones die.

Please leave me your thoughts and ideas for improving this? Is it worth continuing to pursue?

Is The Product Owner Role Hiding a Bigger Issue

2013-10-04T22:56:00.004-07:00

Is the Product Owner/On Site Customer role in Scrum and XP potentially hiding a bigger inventory problem? My thought on this started with a blog post from @duarte_vasco. (please stop and read this to gain context) It also fits with several experiences I have had. But first let me show an example that actually makes the problem visible.

At a company I was working with they could not agree on a single product owner type role. This caused them to create a product owner team for each scrum team. These product owner teams had people from the business, IT and user experience groups from the organization. Of course for many with a Scrum or XP background this clearly brings to the forefront the likelihood of several issues cropping up, multiple priorities given to the team, slowness in agreement on direction, stories that are really small requirements documents, etc. Not surprisingly, that is the case. However, that problem is very visible! The visibility has lead to discussions on how to improve that. I am not completely confident they will create a solution that is significantly better on their first attempt to fix the issue but as long as they keep making it visible they have a chance to.

Other teams I have worked with had this same process happening in the background. The product owner role hid the issue though. Months of work were happening in the background trying to define features, get funding, get buy-in, etc.

The problem is not with the Product Owner role. The problem is we are creating a role without focusing on the real goal, how do we improve the organization's ability to deliver more quickly, understand customer needs and adapt more quickly to market demands.

Moving Visibility and Measurement Up the Ladder

2013-02-01T16:13:00.000-08:00

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

2013-01-28T18:36:00.002-08:00

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

2012-10-10T11:25:00.000-07:00

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

2011-12-15T08:28:00.000-08:00

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

2010-11-26T16:51:00.000-08:00

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

2010-11-25T08:23:00.000-08:00

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

2010-10-19T08:58:00.000-07:00

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.

Agile Basics (A getting started guide)

2010-09-14T07:10:00.001-07:00

* (updated Sept. 16th - new prezi version)

This presentation is meant to show to new teams to help them get started. I wish I could say it was completely unique and completely new, but it is a simplification of some existing presentation with images and ideas from others on the web. Please feel free to use it and give me any feedback you have.

Agile Basics (A Getting Started Guide) on Prezi

Here is an example prezi of how another team implemented these ideas in a year. Thanks Thomas Ferris Nicolaisen for showing this to me.

One Metric to Rule Them All and In the Darkness Bind Them

2010-08-27T16:58:00.001-07:00

I think metrics and measurements are good when used in the correct way based on the context and team I am working with. For each team I am working with I use metrics to help them see what their issues are. Once they see their issues then we use metrics to help us determine as early as possible if changes we are making are having a positive or negative impact on those issues and the rest of the system.

Measurements ARE necessary to know we are headed in the right direction.

There are plenty of articles out there about abusing metrics. I thought it should be well known that all metrics need to be balanced. (e.g. code coverage going up and complexity going down) And of course they need to be trended to be useful.

Now I have a requests to find 1-2 metrics to apply to all teams to determine how effective agile and coaching are doing at improving the teams. Can someone really think that 1-2 metrics can be used to determine effectiveness?

All teams do not have the same highest priority issue(s). Teams with terrible user stories and acceptance criteria do not need the same metrics as a team trying to fix high coupling code issues.

Ok, enough complaining! To help me, and I hope others, I want write about 1) what are the goals of specific metrics 2) what are the dangers and abuses of those metrics? and 3) how to balance those metrics against each other?

Average velocity trend

*Goals:*
* Predictability!! What can be done by a specific date or when can something be completed.
* Velocity is a *capacity* measure *NOT* a productivity measure.
* Velocity allows a team to know how much business value they can deliver over time.
* Developing a consistent velocity allows for more accurate (i.e. predictable) release and iteration planning.

*Possible abuses:*
* Calling this a measure of productivity. If velocity is the only number focused on it could even hurt productivity. Teams can artificially increase velocity in many ways; stop writing unit tests or acceptance test, increase estimates, stop fixing story defects and reduced customer collaboration just to name a few.
* Comparing velocity between teams. Velocity is a team value and not a global value. Many variables affect a team's velocity including relative estimating base, support requirements, number of defects, political environment of the product or project and more.
* Calculating velocity by individual. This leads to a focus on individual performance vs. team performance (i.e. sub optimization).
* Using velocity to commit to the content of an iteration when the value is not valid. Velocity is a simple concept and it provides a lightweight measure, but it is also a very mature measure. To be useful it requires estimation maturity and the consistent application of this over a period of time by a stable team base. If it lacks these elements its abuse can come at the hands of management or from the team, the latter occurring when a team makes assumption about the validity of the metric when, without the mature elements in place, it is not usable at all.

*Balancing metrics:*
* Percentage of rework versus stories done on average each iteration. This can help a team see how much of their work each iteration is delivering new value to the team's customers.
* Planned work versus unplanned work trend. A lot of unplanned work will cause a teams velocity to be of less value because it hinders a team's ability to plan. Having a low value for unplanned work will make the teams planning more consistent and accurate.
* Code quality metrics such as code test coverage, cyclomatic complexity,static error checking and performance. A team that is increasing their velocity by not focusing on code quality is making a short term decision that will have a negative impact over time.

Delivered Features vs. Rework Resolution trend

*Goals:*
* Makes _waste_ visible so that it can be eliminated.
* Gives the team a good understanding of how much of their iteration capacity is consumed by rework (i.e._waste_).

*Possible abuses/issues:*
* Lagging indicator of the team quality.
* Story defects are not worked on until a regression period giving a short term indication of fewer defects.
* Increasing story estimates and/or reducing defect estimates
* Hiding defects as stories.

*Balancing metrics:*
* An inconsistent velocity. Delaying defect correction until later will make the velocity trend erratic with large spikes.
* Planned versus unplanned scope. A team that is delaying defect correction will tend to have more unplanned work due to poor quality issues.
* Number of defects in the backlog. Ideally this number should be on a downward trend. An upward trend of the number of defects in the backlog could indicate the team is delaying defect correction.
* Increasingly long regression periods at the end of each release.

Completed work vs. Carryover trend

*Goals:*
* How well the team is in their execution of the iteration (i.e. delivering on their commitments)

*Possible abuses:*
* Planning less work than the team is capable of to allow for interruptions or poor estimating.
* Delay refactoring code to complete work but not keeping the code at a level that makes change cheaper and easier in the future. (or other good practices such as TDD/unit testing)

*Balancing metrics:*
* A velocity trend that is not improving or is going down could be caused by planning less than the real capacity of the team.
* Planned versus unplanned work can indicate if the team is being interrupted and is causing task switching that could be the cause of the carryover.
* Downward test coverage trend and/or upward cyclomatic complexity trend could indicate that the code is becoming more difficult to change and much more difficult to estimate accurately.

Planned vs. Unplanned Scope trend

*Goals:*
* Show how well the team is at planning.
* Show how often the team is being interrupted within the iteration to work on something that wasn't originally planned.

*Possible abuses:*
* Large place holders to allow unplanned work to come in and appear to be part of the planned work.

*Balancing metrics:*
* Delivered Features vs. Rework Resolution trend.
* Completed work vs. Carryover trend

Code coverage vs. Cyclomatic Complexity trends

*Goals:*
* Reduce the cost of change. Clean code tends to make the application easier to understand and safer to change.
* Indicates that the system is being tested at an accurate level.
* Indicates that the code quality is good; loosely coupled, simple as possible, etc.

*Possible abuses:*
* focusing only on one code metric. e.g. 100% code coverage with generated tests will not make the code easier to understand or change.
* focusing on code quality alone and not focusing on business goals of the customer.

*Balancing metrics:*
* Velocity trend
* Delivered Features vs. Rework Resolution trend
* afferent and efferent coupling trends
* abstractness trend
* package dependency cycles
* number of changes in a class(es)

This is far from an exhaustive list of metrics! But I hope the idea of thinking about a metric and what your goal is of measuring a value and how you can stop yourself or others from gaming the value by balancing it with other methods.

** I started this article based on a set of metrics that my colleague Mike Stout uses, so thanks for the ideas Mike. Several other coaches I work with gave me feedback on this as well. Thanks!

Not Laughing Anymore

2010-08-27T16:44:00.000-07:00

I use to read all the blog posts about the year of Linux on the desktop and laugh. Not because I do not like Linux but simply because it was simply to complex for the average user. But my opinion is changing.

Out of absolute frustration with the poor performance of my new work laptop running XP I decided to install the latest Ubuntu version for duel boot. Wow it was easy and fast. I have been able to do everything on Ubuntu 10.04 that I do on a daily basis. It works within my corporate network seamlessly. It worked at home even better. It is super fast but I am sure this is partially because I get the full 64 bit support that I do not get with XP.

Another great thing is how it feels the same whether I am at home or at the office. Windows XP behaved better outside the corporate network. I do not think this is all Windows fault. I am sure the corporate installed tools are a big part of the problem. But now I am running the evolution email client and it works the same in and out of the office. All the development tools do as well.

I have not been able to connect to the VPN we have, which was done with the Nortel VPN client on Windows. However, I used this to connect to outlook and I do not need it now.

I am still not 100% convinced and it has only been a week but so far Ubuntu is doing great as my corporate and at home OS.

How the Underdog Outperformed the Champ

2010-07-23T22:09:00.000-07:00

This post is a textual version covering the information I covered in my Agile2010 talk in Orlando.

I want to tell you about 3 teams and show how implementing agile practices and slowly begining to understand the principle behind those practices helped them deliver value faster. One of the strange occurrences that happened though was how a more junior team outperformed a more senior team for a very long time.

How the Underdog Outperformed the Champ on Prezi

The story starts with a high profile internet booking engine for a low cost airline. The project was having a rough start and was not making progress. Most of the development was being done in a new office that was located 7 hours away from the office we were located at in Europe. I, an agile coach, moved to this location and a director for the product spent <>

The team started as 1 team that we quickly split into two teams. Soon after we added a third team at the office in Europe.

All 3 teams were new to agile. The teams were setup with 6-7 developers and 1-2 testers. The teams shared two customer representatives/business analysts. They had worked in iterations but the iteration was never a commitment but simply a place to track what was currently being worked on. The original two teams were relatively junior with mostly front-end experience. The third team we added had more years of development experience and more balanced experienced across all tiers of an application.

We started implementing extreme programming practices with the two teams at the same location. The initial focus was on planning and we moved to a 1 week iteration with daily standups. We started doing retrospectives as well and this allowed us to start make fast improvements. Which quickly identified problems with our user stories and acceptance criteria.

We did some user story training, based on Mike Cohn's material, with the team. Then we started working with them to breakdown the stories. This actually took a couple of iterations to get the stories into a size and correct split so that they could be developed and completed in a one week iteration.

The two teams at the original location had a couple of attributes I really appreciated. The first was they were open to change. They wanted to improve and they listened to everything we would recommend as issues came up. One thing that took a bit more convincing but we were able to get them to try was working in a cross discipline way. The whole team focusing on testing when testing took more effort than development or testing was behind.

The team that implemented these ideas the best became very efficient and continually solved their issues. This lead them to have a very consistent velocity. However, it was not only the most consistent it was the highest of all the teams.

The second team struggled with consistency. As we started to implement the process they did have an initial upward turn but they did not consistently solve the root issues that were occurring and struggled to have a consistent output of value.

I will start with a retrospective on the high performing, "underdog", team. The items they were doing that really helped them included focusing on finishing the work in an iteration. The iteration became a commitment that they desired to keep. The divergently searched for ways to do this and improve this.

One of the first issues that really made all the teams suffer was story size, completeness and how they were split. This was a team effort to get this right. The business analysts watched how the team worked and the development and testing team help get stories into a size that both delivered value and was completable in a one week iteration.

At times stories were still too big and were not complete until late in an iteration. This caused the testing to be very high risk. The testing team need assistance and the whole team would help as required. Generally speaking they had, or rather developed, good cooperation between all roles on the team.

As I said earlier the team that did this the best also had a very high output of completed stories and fewer defects.

This team was open to new ideas and wanted to learn. They wanted to be better at planning and technical practices although with the pressure on the time line the technical ended up getting less focus.

One of the issues was the practices were seen as absolutes and understanding the values and principles driving these practices was not completely grasped. This lead to struggles when I left the team for a few months. When I returned they told me what all of their issues were but they were not solving them. No one on the team really developed into the leader, coach and evangelists to keep improving and refocus the team back to the goals of the practices.

There were many technical practices that we did not implement well. One of these that we spent a few weeks on trying to get going was ATDD/BDD. I am a big proponent of doing this and we struggled to get the team to take the time to learn tools and techniques to do this well and it was dropped. Of course the normal problems of not have an automated suite of test came up with each release including many defects and repeated defects and longer manual regression periods that mostly focused on positive and negative checking.

We should have added or developed someone on the team to be the leaders that could have kept the team focused without a full time agile coach.

One of the things I am very thankful for was we did have management support for changing the way we were working all the way to the Senior VP level. They not only allowed us to do it but were removing as many of our roadblocks as possible. Many of these roadblocks were with internal and external teams we integrated with and the team had very little influence or relationship with. They gave the team the contacts to develop the relationships and the support to influence those teams leaders to help meet the teams needs.

Another thing I am thankful for is how well the team accepted me. I came in with authority to make changes and it is very difficult to accept an outsider who is asking you to make huge changes. They quickly allowed me to be a part of the team which allowed me to help them become a better team. This also gave me new friends to help adjust to a new country and culture which is not an easy thing to do.

Now we go to the third team in the story. This team was added a couple of weeks after we had started implementing the changes on the team. They stepped into the system we were creating from a completely different system. They had a few more years experience than the other 2 teams both within our company and outside. They had come from a team that had some level of success working in a different way. They called this way agile but as I mentioned before this was iterations that did not have the commitment of an agile iteration. They were use to working in long release cycles where mostly technical stories and upfront design were done first versus stories that delivered small pieces of business value where the design evolved and refactoring was continuous.

They really fought against the change. They did not see nor did they put effort into understanding the value of how we were working. This ultimately lead to a long period of very low performance. It was not until the last iterations that they became more consistent at delivering high quality value for the customer to use.

There were some things the team did that I liked a lot. They had better design skills and understanding of good design principles. They also fought to get refactorings and removal of some large pieces of technical debt.

But unfortunately there was a lot of room for improvement.

The team did not focus on finishing iteration commitments. This was not a priority. They did not focus on breaking the stories to fit in the iteration. If development was done they did not assists with testing. This lead to an animosity between the developer and the tester and a lot of defects.

The did understand design principles but the idea of simple design and working in small sets of changes was not understood. Refactoring was seen as a big story when things got so bad you could not longer make changes without breaking everything else. This lead to a couple of delayed releases due to large refactorings that would take a week or so to fix all the defects created. Obviously better automated tests of all types would have helped this.

They never worked as a team. Each developer owned their own stories and worked on it alone. The communication between the developers, testers and business analysts was very bad at the beginning. It took a long time to improve this.

They did not find and solve real issues. They usually identified symptoms and avoided digging to the real cause of these symptoms. This meant issues carried on for a long time before they were actually solved. I think part of this was they knew what the real issue was but did not like the possible solutions, like slowing development to help with better testing or working in smaller batches of work.

This team had no one leading for a long time. There was no one on the team who had worked in an agile way and was focused on continuous improvement. Someone was added to help lead the team after a few weeks of struggles but it took a while to get the team turned around.

The team was built from a group of people that really did not understand agile values, principles and practices. This meant myself and one of the business analysts were the only ones trying to show them the value of what we were trying to do with minimal success. One thing we did mid-way through the project was have the team that was performing well do a session with the other teams to tell them what they had been doing and how it helped solve their issues. This helped a bit.

One of the things we tend to struggle with is creating new teams for a project that is growing. We tend to start with too many people at the beginning and when we need to grow a new team we build a whole team from scratch. I think it is "eXtreme Programming Explained" by Kent Beck that says split and existing team to grow a new team. This is more likely to give you a team that is starting with people who understand the application, the current design, the process and the system as a whole.

The less experienced team wanted a set of practices to start with. A senior team needs to have more say. Most people want to improve. Let them fail early but in a way they can get quick feedback. They may still need some guidance and some help asking the right questions but the freedom will reduce the reluctance to change. I believe in most cases the team will fill the pressure to correct the problems they create.

One thing I enjoyed was the debates I had with the leader that was brought on to help the team. He did not agree with everything we were doing, similar to the rest of the team, however he wanted to discuss and understand why. We had long discussions about things we were trying to do and things that were going wrong. In the long run he ended up being a great help in convincing the team to try new things.

So what have I learned on this project.

Getting started with a new teams is hard! There is so much that needs to be considered. Our teams had domain experience and experience with part of our architecture. However, they had not worked as a team together.

The first thing I think you need is a strong leader. By a strong leader I do not mean a dictator. I mean someone who understands the system you are in. The leader should understand the process you will be starting with and understand the values and principles behind that process. This leader must be able to explain those and guide the team towards understanding and using those values and principles in order to continuously improve.

In order to continuously improve the leader and the team must know how to dig deep into the issues and find the root cause of their issues. This requires courage and openness. It is much easier to point at and blame symptoms and/or others for the issues the team has. The team will want to say the problem is "the short iterations", "pair programming" or "the open environment" when the issue is stories are too big and are not clearly understood. Their is a communication problem between developers and testers. The team is guessing when they do not understand versus having a discussing with the customer and/or business analyst. Or many other issues that are usually people related and system related.

One thing I found that helped the team see issues were coming was watching and limiting the amount of working in progress.

Limiting work in progress, like having a goal to avoid carryover, does not fix your problems. However, it is a great indicator that there are issues.

Too much work in progress hides issues and delays feedback. To much work in progress means testing is not fully done, or maybe not done at all, and you are hiding quality issues. It also means the customer cannot see and use the work yet so it delays getting customer feedback. It delays the discovery of all types of communication issues on the team and between the team and third parties they must interact with. To much work in progress also hides the progress. It is difficult to tell where you are when work is not developed, tested and accepted.

One of the interesting things I saw and the reasons I decided to write and talk about this was how I saw experience work against a team and how inexperience "helped" another team. We actually had 2 teams at a couple of different points and they both had the performance issues I discussed earlier.

With a less experienced team you can and probably should give them more of a starting point. A team not familiar with agile planning needs some absolute starting practices to try out. But be-careful that you are always explaining why you are recommending a certain practice. It is a must to mentor them and develop a leaders who understands not only what you are doing but why. If there is no one on the team who can be this find someone you can bring on to the team and develop into this role.

Senior teams need to have a bigger say! They do have some experience so make sure to spend time getting their buy in and let them help set the starting process for the team.

The way we built the 3rd team would have made this difficult because we did not build the team with a base from the existing teams. It would have been extremely difficult to manage teams with different iteration schedules from a release perspective. However, this team was so inconsistent we could not really promise what they would have done in any set of iterations anyway so we still struggled with release scope issues.

Experience is a broad term. I do not think many people believe time based experience is the only or even best measure. Someone that has done something many times and done it the exact same way each time does not have experience. It is unlikely they would be able to or would even try to adapt what they have done when the context changes.

I really like the four levels of experience that Andy Hunt used to describe different levels of experience in his book "Pragmatic Thinking and Learning":

Novice = "...have little or no previous experience in this skill area. ... They can, however, be somewhat effective if they are given context-free rules to follow"

Advanced Beginner = "...can try tasks on their own, but they still have difficulty troubleshooting"

Competent = "...can now develop conceptual models of the problem domain and work with those models effectively. ... Competents can troubleshoot."

Proficient = "need the big picture", "will be very frustrated by oversimplified information" and "can self-correct"

A team lead I worked with recently had great success limiting his small team to 3 stories in progress at once. When he moved to lead a team that was more than double the size he wanted them to keep the same WIP limit as the small team. The team was very unhappy because they were not staying busy and they knew they could do more than they were doing. He had learned a practice but could not adjust it to the new context yet.

I hope this helps you and please comment and ask questions. I am still learning too!!!

GivWenZen for Flex

2010-06-24T18:03:00.000-07:00

Very cool, I was sent a link to a new clone of GivWenZen for flex. Looks very interesting: http://bitbucket.org/loomis/givwenzen-flex/wiki/Home

GivWenZen Beta 10 - Vararg Support for Step Parameters

2010-04-11T20:15:00.000-07:00

I have finished packaging the new GivWenZen 1.0 beta 10 release. Someday I may not call it a beta but not sure I am ready for that.

The most interesting new feature was the ability to allow varargs for step parameters. A specification can now have something like the following:

given: the numbers 3, 6,12, 67

The step method to handle this could look like this:

@DomainStep("the numbers (.*)"

public setTheNumbers(int... numbers) {

// implementation here

}

This will work for all native types, String and any type that can use the normal PropertyEditor conversion of GivWenZen.

While doing this I realized that there needed to be a convention in place for automatically loading a step parameter conversion type, an implementation of MethodParameterParser, when starting a GivWenZen instance. That is now possible by placing a class that implements MethodParameterParser in the bdd.parse package. As with other custom types they are used before the default converters are used.

A few other small issues were fixed and the full list can be found here.

Eclipse Plugin for GivWenZen

2010-03-23T19:31:00.000-07:00

One of the weaknesses of most BDD and collaborative acceptance testing tools is the lack of nice tools for maintaining them. What I hope is only a first step in correcting this is a new eclipse plugin for GivWenZen.

The plugin adds simple highlighting to the content.txt test file showing missing step implementations. It also allows navigation from the content.txt test to the implemented step method. If you search for usages of a step method it will show both java and content.txt files.

He has also done a nice 2 minute screeencast:

I am adding a task to create a similar plugin for IntelliJ to my todo list. Thanks for creating this plugin Szczepan!!

WesWilliams

What Caused Your Success?

Of course I know why I am successful, I am talented :-)

Of course I know why things didn't go well, it's those other people :-(

Surely, there is a way of operating that does not need to blame

Working Agreements

Alignment vs Agreement

Agile Process Coach, Really?

Manifesto for Blame Driven Development

Accomplishment and Satisfaction Over Happiness

“You may not control all the events that happen to you, but you can decide not to be reduced by them.”― Maya Angelou

hap·py

Shu-Ha-Ri Applied

Who gets value

Give me something for nothing

I don't want to use your form or enter data

Challenge

It is also value not format

Starting with Teams Requires Fixing the System

Formative Organizations - Introduction

The Problem

The Direction

The Formative Organization Idea

Set a vision and create a goal to deliver that vision fast with integrity, learning and adaptability.

The primary source of principles and practices for creating Formative Organizations

Integrity

Delivery

Learning and Adaptability

Conclusion

Is The Product Owner Role Hiding a Bigger Issue

Moving Visibility and Measurement Up the Ladder

More visibility up the organization ladder

Agile visibility

System visibility

Conclusion

Collaboration Not Compromise Or Control

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

Most would agree control is not collaboration (I think)

Compromise is (usually) not collaboration either

So what is collaboration?

Conclusion

Stuck in the Past or About to Be

Agile is Festivus All Year Long

Most Important Agile Team Role

Fix Ubuntu 10.10 Sony Vaio Sleep/Hibernate Issue

Google and Fraud

Agile Basics (A getting started guide)

One Metric to Rule Them All and In the Darkness Bind Them

Not Laughing Anymore

How the Underdog Outperformed the Champ

GivWenZen for Flex

GivWenZen Beta 10 - Vararg Support for Step Parameters

Eclipse Plugin for GivWenZen

“You may not control all the events that happen to you, but you can decide not to be reduced by them.”
― Maya Angelou