Agile Ethics

Agile started as a discussion of lightweight software development methods. At least, this is why in February 2001, 17 software developers met at the Snowbird, Utah resort. When I talk to people about what attracts them to Agile, I frequently hear that simplicity of approach resonates with them. Remove unnecessary complexities and waste, and do whatever is meaningful and productive, in a way that works now and here. That is beautiful.

This is not what attracted me to Agile as a concept though. I was fascinated by a simple fact that those people were talking about efficient ways of writing code, and yet they started with values. This did resonate with me. Developing machine code and thinking values – as counter intuitive as it may seem and as organic as it can possibly be.

I have been thinking about the value of having values recently. Specifically,  starting last week. I am trying to comprehend the concept of “prioritizing values”. How can you prioritize values? It’s either a value and then it is a priority, or it’s not, and then, there is no need to prioritize anything. Have you heard of work/life balance?  “I have my values but I am doing whatever is best for my family.” Does it mean I can lie or I can betray someone’s trust if I think this is best for my family? This puzzles me and yet, as a Coach, I hear it sometimes.

Throughout years, I’ve learned to understand the concept of “work/life” balance and yet I do not get it. When I am talking to my colleague or helping my son do his homework, am I a different person? Do I divide “me-at work” and “me-at home”? Do I have different values depending on where I am and what I do? Do I feel happy in a different way when my code finally compiled, or when an employee got a chance he has been waiting for, or when my son does subtraction without counting physical objects? Am I working when I write my Agile blog at 2 am in the morning or am I actually relaxing because I enjoy doing it? I think that the concept of “work/life” is made up by unhappy people who think that when work ends, life starts. Luckily, not so for many of us.

Going back to ethics. When I was a child, ethics for me was no different than etiquette. I associated ethics with eating with the right fork and it seemed to me just another unnecessary constraint humans establish to add unnecessary complexity to their lives. As a child, I implemented a lightweight process of eating everything with a spoon. Worked for me.

When I learned that ethics is a set of moral principles, the concept seemed even duller. Until a week ago when I finally understood why Agile is more than a framework for me. What resonates with me that these 17 people in Utah came up with the principles based on their beliefs. They did not think in terms of “work/life balance” or “I hate to do this to my team but I have to do whatever is best for my family”, they thought about what matters most and based their principles on the values they believe in. This is what ethics is for me. It’s our beliefs in what is right and what is wrong. And right for my team and right for my family are not in conflict. Just because there is one right, and it is the choice that I make.

 I believe that it is not material that the product of this Utah gathering was the Agile framework of software development. If this group of people were in aviation, they would envision an amazing plane which will fly faster than any other comparable plane. If it were an economics theory, it would explain many processes in the modern world that we are still trying to comprehend.

No matter what the area of knowledge is – right values create meaningful things, and this is what Agile is for me. Meaningful approach based on firm beliefs in right or wrong that resonate with me. And I find it hard to believe in “what is best for my family” concept because our values do not change when we come home from work. Otherwise Utah gathering would never happen.

Workplace 2020

 

I do not believe in coincidences. Actually, I do. I just think that most coincidences only seem to be such. Each time I am amazed by a coincidence and start thinking about it, I manage to figure out the reason for it. Here’s a recent example. I read a book about 2020 Workplace and listened to a presentation by Agile coaches at Spotify at NYC Scrum.  There were multiple great points in each, but two parallel thoughts fascinated me.

The book described the onboarding process in a 2020 company. A new employee joins the company. Actually, it is not exactly a new employee because she has been coached by the company and introduced to its business since middle school. But today, during the first day of her employment, she is having virtual meetings with three potential managers who share their vision and suggest work responsibilities to her, hoping that she will select each of them as a manager. And she is responsibly taking the challenge of finding the one whose vision and passion to the work resonates with her. And once she chooses this manager, she will rotate throughout the company during the first year of her employment growing to know the business and people until the chooses where she'd like to work.

The presentation from Spotify coaches was staged as an onboarding process where all participants had to imagine that it’s our first day with the company, and the coaches are telling us a compelling story of company’s values, structure, opportunities, and innovative ways to engage employees. They were not talking about Agile principles, rules, ceremonies. They were talking about the spirit, the “guilds” that promote employee collaboration based on their interests, about support within domain-based "chapters", the unity of "tribes", the ease of choosing and moving to a team, and freedom in selecting practices that work for a team.

I was talking to product owner today about killing team’s motivation with constantly changing priorities, about demotivating them by not releasing their work into production and by not sharing any actual impact of their work with them. And the product owner told me he has nothing to do with it because he has no choice. He depends on his manager, and his manager depends on his bonus. Plain Maslow's hierarchy of needs. No choice here.

All of a sudden it struck me what I liked in the book and the presentation above and what I do not understand in this product owner’s reasoning. 

In the book and in the presentation, the freedom of choice is as organic as ability to breathe. This is what makes us people, this is what motivates us and makes our lives meaningful. World literature is based on the dilemma whether we have choice over our destiny, or our lives are pre-determined by an outside power or environment we're in, whichever it may be. 

In order for our professional life to be meaningful, we want to be able to make our choices, good or bad – but those will be the choices we made. Not the product owner, not the circumstances, not even ROI – we want to work on things that are meaningful, on things that matter to us, and do so with the people we trust who motivate and inspire us. And we want to be able to make a choice.

This is what my responsibility as an Agile coach is: to ensure that teams have choice in making their professional life meaningful and their work emotionally rewarding. I just wish I could find better words in sharing my vision with the product owner. I am not giving up though. Not until his team is giving him another chance. I’ll buy him “The 2020 Workplace” for Christmas. Or Daniel Pink’s “Drive”. Or share Henrik Kniberg’s 15-minute speech about the essence of Agile. I am not giving up on him – he deserves having a choice, too.

My NYC Agile Day 2012 Observations, or IT is All About Simplicity

On September 20, 2012, Ilio Krumins-Beens and I co-presented at Agile Day NYC. It was a wonderful energizing event with several hundred participants from all over the world masterfully organized by Joe Krebs and the team.  I was excited to meet Harrison Owen, inventor of Open Space, who presented at a self-organization track and also participated in the Open Space next day. I was excited to meet Dave Thomas. I follow Dave on twitter and always enjoy hearing his perspective, whether he talks about lean principles or  suggests to retire object oriented programming. Dave is always mind provoking, never boring. Another topic of interest was a participatory workshop of advanced social games led by Stanley Pollack who uses these games with NYC youth to promote friendship and overcome violence. And of course, it was exciting to present and to hear feedback from the participants.

All the presentations I listened to were outstanding. I attended keynote by David Thomas who spoke about a number of topics he is passionate about: lean, OOO principles, requirement elicitation, customer experience. However, throughout all his speech there was one major thought: seek simplicity, do not try to over-engineer - neither the process, nor the technology. According to Dave, OOP is unnecessarily complex, why can’t you use a flat data file or Atom feed? Why would you try to create a 1000-page requirements document if the users in a neighboring department have already automated functionality using excel spreadsheet? Open your eyes, look around. Be simple. Simplicity is organic. It is natural. That’s what we all should be looking for.

Surprisingly, this was the note of Harrison Owen’s presentation at self-organizing track, too. We, human beings, try to plan and control. We create meetings with long agendas and fail answering questions. What is the natural way for a meeting? Invite those who’d like to contribute, those who are passionate, those who are interested, and if they exist, they will come. Don’t bother bringing in others because they will not add value, they will only demotivate the ones you are actually looking for. Bring in those who WANT to contribute. Don’t answer, ask questions. 

The following day, at Open Space, Douglas from American Express asked Joe Krebs and me a beautiful question: “would they come if …?” Would they do it (whatever it is) if they were not paid for doing it? Would they treat you with such a high respect if you were not their manager? Would they work as hard if they did not expect a reward? 

Eva told me that Ilio’s and mine presentation stood out among others. I was surprised because it was a day of excellent presentations and asked why. The answer was “because you are not professional speakers. Because you speak from your heart and it shows.” Isn’t that the power of simplicity? Talk about something you care about in the way that you feel about it. Nothing more simple that that. Thank you, Eva, for this simple and yet so profound thought.

And finally, at a games session, Stanley Pollack taught us how to unleash the way we feel and not be afraid to show it. After five minutes of the “tossing bag” game where I was blocking the flow of throwing the bags which were falling all around me, Staley and Heang asked us what we felt about the team members. When throwing and catching bags, all I could think of not dropping them, but once asked the right question, I said that I think Marco who threw bags to me paused to let me catch up at the expense of having Maria (who was throwing bags to him) being upset to him for failing to catch, and I found that Marco very thoughtful. In addition, Monica who was getting the bags from me, never showed any disappointment that I started throwing her pairs of bags trying to catch up, and after couple of attempts became very skillful in this role. I liked that she did not show me disapproval nor gave up despite having to get a few bags from the floor. Just a few minutes spent with a group of people I’ve never met before, several brief conversations, couple of games, and there is one thing I know for sure: I want to be on a team with Marco and Monica. No complex interviews, no tests designed by psychologists, just a simple workshop, and in the end, I know who I am compatible with professionally and psychologically. We humans are complex systems, no question, but the way we feel, think, change, self-organize, is actually very simple. Because simplicity is organic for us despite all our attempts to create complex rules and regulations. Same thought again.

When I was leaving the Open Space next day, Mary Pratt told me something that perfectly concluded these two amazing days. She  reminded Ambika and me that Agile evolved from something that was called “lightweight software development methods”. No wonder simplicity was my tune throughout two NYC Agile Days. 

Thank you, Joe, Ilio, Heather, Dave, Mary, Monica, Ambika, Marco, Douglas, Harrison, Stanley, Heang, and many old and new friends that I met at Agile NYC Day and the Open Space. We share interest in Agile, desire to learn, and passion of sharing. What can be more simple than that?

Agile Certifications

Further to my previous post on PMI-ACP, below is a link to my prezi.com list of Agile and other relevant certifications:
http://prezi.com/_7xp7tjkhczo/agile-certifications/

The most important point about taking certification for me is the cause. If the cause is to get a promotion, this may have some immediate motivation for some, but they rarely succeed. If the cause is to be better contributor to the team, it is a good cause and this individual has more chances at passing certification exam.

In terms of which certification is better, it is more about you personally. Who are you - scrum master or you have project management background? Are you on a scrum team or you use a different Agile framework? What certifications you already have? What is your primary role on the team? Add this information to your professional desires and beliefs and do not worry which certification is more prestigious. It is all about what is right for you!

Performance Reviews in Agile

In my two previous blog postings, I wrote about performance reviews from employee's and manager's standpoint. Here's what I think overall (will be glad to hear from you too).


Feedback is important for human beings and it is one of the most important means of development. I agree that performance reviews are not the most effective way of obtaining feedback especially in Agile environment where there are a built-in mechanism for feedback, which is a retrospective. Effective retrospectives enforce Agile values and come from your peers. However, I still support all types of reviews in a corporate environment because it contributes to the atmosphere of transparency and continuous inspection and adaption, which are important Agile values.

There are several drawbacks but they can be mitigated:
1. People do not like to be judged. - Be non-judgmental in your feedback and prepare to take feedback from others constructively and continuously. It feels good once you get into the habit.

2. People are sensitive to feedback. - It is important to create tolerance for risk. If people are comfortable to try, make mistakes, and try again, they need feedback to succeed. Once this understanding becomes your organizational culture, feedback is welcomed rather than causes frustration from the recipient.

3. People get feedback but don't act on it. - Help your colleagues define professional goals that work for them and create such an environment where they will have an opportunity to share their success with others.

So my solution to ineffective performance reviews is: decouple performance appraisals from career development and more importantly, from compensation evaluation. Establish continuous feedback flow and a consistent and fair compensation system which does not depend on annual review. Whether it is google's promotion system or Valve's "select a peer" system, do not base it on performance reviews.

How does it work in Agile? This year, I added management responsibilities to my Agile coach role. This made me think of how we can utilize annual performance process effectively to grow our scrum masters. As a result, I decided to use goal setting process in such a way that scrum masters think about supporting company's business objectives and establish common goals for all the 12 scrum masters and their teams. We did brainstorming jointly (of course, we used stickies, silent grouping, and voting) and came up with 3 high-level goals: improve accuracy of planning, increase reliability of commit (there were KPIs associated with this to make this goal measurable, differing between teams), building self-organizing teams (this translated into different specific goals for each scrum master), and maturing product backlog quality. Each scrum master has a set of specific measurable (S.M.A.R.T.) goals associated with one of those, and will seek continuous feedback from the team, adjust accordingly, inspect and adapt.

How does it all translate to performance appraisals? First, those should not happen once a year, there should be continuous feedback, and all parties should be open to it. Second, it does not have to come from your manager, I think it is important to welcome any feedback you can get and not feel hurt or upset, kind of grow thick skin and take any feedback constructively. Third, think of it as of a way to help you become better, or help your peers become better, not as an input for your salary increase.

To sum it up, I agree with Mary Poppendieck that it is important to create an environment where you have a coach, presented with a challenge (Mihaly Csikszentmihalyi's flow), provide and are open to feedback, and foster dedication. How you do it is up to you, but if you find an effective way to incorporate performance reviews in this process, go ahead. Just remember not to be judgmental, rather, use it as a feedback mechanism and as an input to creating goals for your colleagues that will help them become better professionals, better leaders, and better team contributors.

On performance reviews - from manager's standpoint

This posting is Part 2 of my posts on performance reviews. These two postings are easier to read as a sequence because all of us are the recipients of  a performance review, but only managers have both experiences. Before I became a manager, I thought of performance review as a time and effort consuming but very rewarding process for a manager. I have seen a few managers doing it really well and helping employees with assessing their strength and opportunities for improvement, and coming up with a solid plan to work on those. This is a direct opportunity to develop your staff and make a positive difference in their professional growth.

I've heard from some managers that they provide ongoing feedback and if their direct reports need performance review, it means that a manager is not doing a good job. Take a pause for a second and reflect on this thought. Do you agree? As nice as it sounds, I personally do not. Ongoing feedback does not replace the need for detailed cumulative feedback which will then provide direct input into development goals and planning for this employee for the coming year, as well as into promotions and increases (or lack of those) for this employee. This does not have to happen once a month, I personally found out that once a quarter is a good frequency, but it is different from immediate feedback.

What are the inputs into performance review?
1. Last year's performance review and list of development and performance goals (if applicable).
2. Company-wide guidelines on the process and any pre-defined skills in the appraisal system for this role.
3. Role description for this position.
4. Feedback from multiple stakeholders from Business and Technology (if applicable) in different categories.
5. Your data/facts throughout the period of review and your opinion as a manager.

What is the output?
1. Weaknesses and strengths defined, discussed, and agreed upon.
2. Honest conversation about opportunities for improvement.
3. You either discuss development goals at this meeting or right after.
4. For the performance goals, you will have to collect input from you team, product owner (if Agile), business sponsor, and other stakeholders as relevant.
5. Good feeling of creating self-awareness and a plan to accomplish the employees professional aspirations on an individual basis.

Does it always happen? If you are a good manager, then often.What are the challenges? I've experienced three most common ones:
1. The employee is not interested in a dialog (tired, busy, does not see value, etc.) Whichever the reason is, manager's goal is to explain value while choosing more comfortable time.
2. Employee disagrees, e.g. if a manager suggests to improve a skill, and employee responds that this is actually his or her strength while assuming the manager is just not aware of what s/he is accomplishing. In this case, I suggest that the manager takes a genuine effort to observe this employee well enough to be able to assess the value provided, and if the employee lacks self-awareness, provide open feedback or do one of self-awareness exercises, e.g. http://www.estherderby.com/2012/05/self-awareness-matters-finding-your-filters.html.
3. Sometimes all employee is concerned about is tying performance to salary increase. Performance review is the time to review employee's strength and opportunities for improvement, as well as further growth. I do not suggest to discuss salary or promotions during performance review. It is important to explain that while there is impact, there is no immediate direct dependency, e.g.high appraisal does not immediately result in title and salary increase. Those employees have to be educated about the purpose of performance review. Manager's responsibility in this case is demonstrating value of this process for employee's development.

What do you think?

Scrum Master - Role or Profession

http://www.agileconnection.com/article/scrummaster-role-or-title

On Performance Reviews (from employee standpoint)

Many people hate annual performance reviews for a number of valid reasons. At a recent conference, I sat next to an engineering manager with 14 direct reports who told me: “If my employees ever need a performance review, it means that I am a poor manager.” His point was that if he does not provide ongoing feedback and needs once-a-year campaign for this, then he is not a good manager. There is even a book by Samuel Culbert “Get Rid of the Performance Review!: How Companies Can Stop Intimidating, Start Managing – and Focus on What Really Matters.”

S. Culbert identifies 12 problems with performance reviews:

1.           Performance reviews focus on finding faults and placing blame.

2.           Performance reviews focus on deviations from some ideal as weaknesses.

3.           Performance reviews are about comparing employees.

4.           Performance reviews create a competition between boss and subordinate.

5.           Performance reviews are one-side-accountable and boss-dominated monologues.

6.           Performance reviews are thunderbolt from on high, with the boss speaking for the company.

7.           Performance reviews mean that if the subordinate screws up, then the subordinate suffers.

8.           Performance reviews allow the big boss to go on autopilot.

9.           The performance review is a scheduled event.

10.         Performance reviews give HR people too much power.

11.         Performance reviews don’t lead to anything of substance.

12.         Performance reviews are hated, and managers and subordinates avoid doing them until they have to.

There is even a web site:  http://ihateperformancereviews.com. As it is stated there, “We hate performance reviews. We don't hate the idea behind them, we hate how most big corporations implement them. It's inefficient. It doesn't work. “ Guess what they tell you next? “We're here to change that. We make performance reviews work for you.” What is your take away? Mine is: “It is not performance review concept that is bad. It is poor implementations that make it inefficient and sometimes even harmful.” This reminds me of Agile. I believe in Agile because I know it works. When I am told that Agile is no good, I know I am dealing with a poor implementation of this framework.

So – I know this too well myself. At my previous job, I hated performance reviews. They were totally inefficient. Throughout a year, my manager was carefully maintaining a list of my successes and failures and took pride in making my performance reviews highly detailed. I was well aware of my failures and successes myself, so this did not add any value except for the ratings that I got. For me, these ratings are an HR tool, I do not need them, I have my own scale of measuring my successes and failures based on the effort/courage/risk that I took, and no one knows that better than I. If the ratings were used for salary increases, then having them would make some sense. Interestingly though, the year that I got an average of “outstanding”, I got 0 salary increase because by that time my salary was at the limit of my position range anyway. I did not get a title increase either, so I wondered why my time was even wasted on reviewing something I was aware of with the ratings that have no impact on anything. 

And this was not my time only. My manager was a highly intelligent professional whose time could have been better spent otherwise, and in addition, performance reviews were not his strong point anyway. I remember that during a performance review, I gave him my feedback and he stated that this is my review, not his, so this is the wrong time for that conversation. But this will be covered in my next blog post on managerial view on performance review.

First year into my current job, I had my first performance review which totally changed the way I thought about this process. My manager provides ongoing feedback on a daily basis which I appreciate and find very helpful. While daily input highlights specific examples, situations, behaviors, it takes an extra step to see a pattern. This is what annual review is like. While my annual review had specific examples, it indicated my areas of strength and weaknesses, many of them I was aware but did not think they were that obvious, some of them I was not aware and did not know my actions were perceived this way. During my performance review, I shared some thoughts on how I am planning to improve identified weaknesses, and got specific input and advice on those. In addition, my manager got feedback from a significant number of our colleagues in different roles – manager, product owner, scrum master, team member, executive director - and gave me citations without specifying their names. He insisted that respondents provided opportunities for improvement, so the feedback was specific and actionable. I loved it.

What did I learn about myself?

I am rigid. Hmm… I never thought of myself as rigid, and I still don’t. I listen and I am eager to compromise and put myself in others’ shoes regarding things that are not of a primary importance to me. As an Agile Coach, I am passionate though regarding things that I believe in such as standing at standup meetings, or having a scheduled day/time for sprint reviews (demo), and I take time to talk to the teams about the reasoning and the negative impact of sit-down standups or demos with no stakeholders because of last minute notice where the team feel discouraged rather than excited. And I always state it to the teams and I thought that this knowledge is well received, but I found out this is not the case.

What I learned though is that I am perceived as rigid. This was the biggest win. I did not adjust my beliefs, I adjusted my behavior. So I talk more about the reasons and – unlike me a year ago – I let teams try and fail (any they inevitably fail), and then we discuss the reasons at a retro and go back to standing standups and repeated demos. And sometimes teams continue this practice (I have one team that strongly feels this way) and this hurts their productivity, and – you know what – I am not going to force them, but I will continue providing feedback and working with them until they mature enough to see the value in standing. And for now – let them sit at a table checking their smart phones and losing focus – and I am not going to force them but I will highlight specific cases when participants do not hear questions they are being asked or replies are not related to the topic.

Actually, I think I have been a little bit rigid and I still am – at heart – but now I know that you cannot force people do right things, you have to give them time to understand this. Otherwise they will eventually roll back to bad practices anyway. Such a basic wisdom but it took me a performance review to figure it out.

What else did I learn?

Opinions are subjective. One respondent says that my communication is highly efficient, the other says that my communication needs to be improved. A set of post-presentation surveys gave my presentations a high average rating of 3.8 out of 4, while one of respondents says that my presentation skills are poor. A question: Should it bother you if you get any controversial reviews? My answer is: No. It is important for me not to take any of this controversial feedback personally but, rather, seek for ways of improvement. Even if I am good in something, negative response means that there are still ways to improve (aren’t there always?). So what I derived is my communication may be good but the level of details has to be better targeted to the level of my audience. Or, my presentations are generally not bad but I tend to speak fast and I should ask for more input from the audience.

Based on my performance review and citations provided, I came up with my improvement list and then improvement plan. Once I compiled the list, I put it on the wall and the file on my desktop. I check it frequently and I move ahead with my plan. I may not become the best presenter in the world (maybe not even on my team), but I know that I am getting better. I have read some books, listened to a few outstanding speeches, gave it some thought, and practiced a lot. So – right or wrong – this feedback was a great trigger for me to work on something and become better in it. And I told my manager that it has been my best performance review ever. I got great input into setting up goals for this year and inspiration to work on a number of good things, which I know will make me a better professional.

So – the point that I am making: performance appraisal process is good. It is bad implementations that make it inefficient. I encourage you to think how you can take advantage of your performance appraisal, what questions you can ask your manager, and which action items plan after you get it.

My next blog posting is on a different perspective. This one was from employee standpoint. In the next one, I will talk about what you can do for your direct reports as a manager but I plan to do it differently. I won’t talk about how you can benefit from the process, rather, I will talk about greatest mistakes managers do in their performance appraisals and how these mistakes may hurt their employees and their morale, and even lead to consequences these managers would never foresee. Trust me – I have made some of these mistakes myself and suffered from others, so I will be glad to share my firsthand experience with you.

I welcome any feedback. What is your experience with performance appraisals? Did you ever find those helpful?

On Pareto Principle

It has been many years since as a part of the Online IT team at a media company, I was part of the team effort in self-training in agile including prioritization techniques. During our mock up scoping exercise, a concept came up that 80% of value come out of 20% of requirements. We discussed where 80-20 concept applies in software development some further and came up with quite a long list of how this principle applies: 20% percent of project deliver 80% of value , or 20% of the team members deliver 80% of work. The latter has to be validated though – I hope this is Pareto exception J

Then, a few month later, I took an advanced project management class and learned about the Pareto chart and distribution types and where and how it applies.

Vilfredo Federico Damaso Pareto (http://en.wikipedia.org/wiki/Vilfredo_Pareto ) (15 July 1848 – 19 August 1923), born Wilfried Fritz Pareto, was an Italian engineer, sociologist, economist, and philosopher. He made several important contributions to economics, particularly in the study of income distribution and in the analysis of individuals' choices. He was the first to discover that income follows a Pareto distribution, which is a power law probability distribution. The pareto principle was named after him and built on observations of his such as that 80% of the land in Italy was owned by 20% of the population.

The Pareto principle, also known as 80-20 rule, helps define efficiencies for multiple systems – in software development and far beyond. Not that is universally applies – but thinking about this rule helps re-evaluate approach to project scope, resource allocation, and personal productivity. How? Just one example. In agile prioritization while prioritizing features and placing those on sprint backlog, we can try to identify those 20% that will actually bring 80% of value and acknowledge that while product backlog is never exhausted by deifnition, we are constantly delivering the need 80% to the business.

Hmmm. How universally is the distribution actually applicable? We are not talking income in Italia – can we apply this curve to software development? One of my colleagues actually tried to apply bell curve distribution to performance appraisals at an HR seminar on the topic. I personally advise against applying Pareto principle to bonus distribution though J

The 80-20 rule is applicable to multiple other situations and environment. Please provide your suggestions – and the one who provides the best input will receive a Pareto award. The winner will be selected by a poll – so total transparency and fairness is guaranteed.

And in conclusion, what is obvious to me is that 20% of the readers of this blog post will provide 80% of the valuable comments and Pareto samples. Are you in?

P.S. This  posting is my first attempt of taking a different look at familiar concepts. I’ll see whether it is of an interest to you. If it is, I am ready to continue with a new look at Deming and Plan-Do-Check-Act cycle. Or maybe you have your own views or suggestions for good candidates for the “Known Unknowns” category. Or does “Unfamiliar Familiars” sound better?

On Leadership

What is the modern perception of a leader? How is it different from what it was ten years ago? How it is applicable to our everyday work reality? No matter whether you a in a managerial title or not, did you ask yourself this type of questions?

Not that I have an answer. But I think it’s important to ask those questions once in a while. Each of us is a leader – in one capacity or another – but not always we realize that, or acknowledge the responsibility that comes with leading others.

I know what was a common perception of a leader in a workplace ten years ago. Someone knowledgeable who has the answers and provides clear and detailed directions to the team. Good communicator. Fair. More like a mentor and advisor.

How is team motivated in this case? It’s easy. As Agile Manifesto states, we are all good citizens. Team members in general want to please their managers and to be considered good contributors by  their peers. It’s in human nature. Things may get different but that’s for a different topic. So level 1 in team quality – compliance – is easy to achieve.

What this approach lacks? Buy-in from the team. Thus – level 2 in team quality: creativity. Level 3: Sense of ownership. Growth opportunity – in literal sense. Ability to grow up as a professional and start making decisions on your own. In the case of a decision-making manager, this is a leader by title and a governance tool but not someone who serves the team in terms of team-building and providing the members with the opportunities they need to succeed.

Is this getting different in a modern world? It is and it is not. People are not necessarily changing easily. In technology, however, we are more prone to change – because of the nature of our industry. We won’t survive professionally without constant learning – and this means the change by default. That’s why agile concept – self-organizing and self-building (self-maturing, self-governing, etc. etc.) teams – emerged in IT.

This does not mean that we lack managers who give orders – and teams are following those (remember, we are all good citizens by nature), however, we have the new breed coming – those who see management function in serving their teams – making them more efficient by satisfying their needs – shifting decision making and ownership to their members and empowering them with ability to think creatively and take  ownership. And the process has started – and I can see it well with the emerging USES agile team – and not just IT members of the team. And it’s a good picture.

I really like the concept of leadership as a service. And this concept is not a new one. Mahatma Gandhi said: “The best way to find yourself is to lose yourself in the service of others.” This concept perfectly applies to project management, any other area of management, or leadersip in general. It is so important to be a servant, not a manager who gives instructions but leader as a team member who builds trust and promotes respect. This is the key to team’s success.

I listened to a webinar on leadership and project management. The presenter was talking on  leadersip and success as it relates to project management. She said: number one driver for project success – guess what? Business case with proper ROI calculated? Resources? Careful planning? Fixed scope? No! Trust between team members. If this is not achieved, this results in slower delivery, lower quality, knowledge trasfer gaps, high maintenance costs. And number one recipe for failure? The environment where people are afraid to admit their mistakes, where collaboration is not promoted, where individual success is above team’s success.

And this is fundamental. Project success is not about technologies and processes. It is about people. So if we fail as a team, it means that we are not ready to take ownership, to makes decisions, to put our success as a team over each member’s personal contribution.

And what is leader’s role on the team? Serve the team by building it based on trust, respect, open communication. That’s why a new term comes into play: leadership as a service. I think this term reflects the nature of modern leadership very well, and a manager is a service provider to the team in the same sense as SAAS vendor provides a service to its customer.

What do you think?

How My Team Decomposed Agile

Below is my submission to NY SPIN Process Nightmare Session in April 2012. This submission was selected, and I had a chance to present to the audience of software professionals. It was a great experience both having a chance to present and to listed to my fellow presenters about their experience. My favorite question from the audience was "If you did it all over again, what would you do differently"? Guess what I answered?

Anyway, below is the submission.

An “Agile Hammer”

(How my team decomposed agile)

Summary. Have you ever heard of a hammer analogy when people talk about scrum adoption? Imagine you need to put a nail down and decide to use a hammer, but you do not see the value or just don’t know how to use the hammer. So you decide to decompose it into two parts. Now you can use a handle or the metal part to put the nail down, and either part is more effective than a bare fist. But only when you use the hammer as a whole the way it’s intended to be used, you will be able to achieve true efficiency. This is what my story is about: how my team adopted agile by decomposing it, and as we were progressing with our implementation, we realized the value of all the missing ceremonies and ended up with an efficient “agile hammer”.        

How did it happen?

In 2005, when Agile adoption rates according to Forrester research were about 15%, I was a project manager on a team of 13 (6 developers, 3QA, 2 BAs, dev manager, and I) responsible for development and support of an enterprise level proprietary application. We were a waterfall shop and I quite enjoyed my role of a PM – my 10-page Gantt charts gave me a sense of accomplishment and I felt I was in control as long as my MS Project Plan was updated on a daily basis. The only downsize was normally towards the end of the project when I was able to accurately assess progress and it would become obvious that after 6 months of hard work and one week into QA testing we are completely off track and something needs to be urgently done. Then, I would alert my business stakeholders, risk and issue logs would start growing exponentially, and for another 3 months my team would lose any sleep trying to catch up. 4 QA cycles later, after descoping or phasing out nearly 50% of functionality, we would deliver working software, then struggle to fix post-production defects for another two or three weeks, and after celebrating the fact that the nightmare of that release is behind, we would start new projects slowly, giving a chance to developers to relax a little bit during requirements gathering. Despite the team working crazy hours, the business was never appreciative citing long time to market, low quality, and lack of visibility into the project progress.

And then one day dev manager called a meeting and said: We are going Agile. I thought he meant: We are going crazy – because at that time we were into the “meet-the deadline-or-die” phase of the project when the business informed us that because of a competitive product which was just release, the work we were doing for 6+ months was useless and we had to start requirements gathering cycle all over again. So I asked what he meant by Agile, and he said that this is a new framework which will help us adapt to the changing business needs and we would be able to produce working software within two weeks. We all laughed. Our application was a multi-tier multi-technology enterprise level platform with a distributed team in 3 countries working on it – how was that possible? Quite possible, he said, and here are the rules: you meet every day for 15 minutes, have a business stakeholder dedicated to the team and available every day, you stop doing hourly estimations and assign abstract point to your requirements, which are not requirements any more – they are called stories, and when you are done, you invite the stakeholders and show them the work. We said that it is insane to move from 9 and 12-month projects to two weeks, and besides, how do we know if it works? Retros, he said, it’s like lessons learned, we will inspect and adapt, and this way we will continuously improve our practices.

We decided to give it a try. The first few months were a nightmare. Our daily “sit down” meetings were one hour long, we were constantly stepping on each other toes. Our product owner was telling the team to switch to a different project mid-sprint. Acceptance criteria were not available. Product backlog was not prioritized. We decided not even to try estimation – this was too complex to grasp. We were not meeting our commitments. Our retros were more about complaining how painful this experience is and how we miss waterfall with uneven load and unhappy business stakeholders. We started moving towards agile more: implemented story point estimation, started to stand during daily meetings which miraculously became shorter, started parking discussions and answering only three standard questions, our retro became focused with action items which we were tracking. The business gave us a stellar feedback, and after sprint 5, we were stunned when someone on the team noticed that we stopped having post-production defects. However, we still had our mini-waterfall within each sprint: requirements gathering, development, QA, and UAT. We even split the team into two, so that their cycle overlap and eliminate productivity loss. We thought we were doing as well as it is possible until a during sprint 12, someone from QA said that she wanted to do some development and was successfully trained. One sprint later, we need additional QA resources and one of the developers volunteered to help. We merged back into one cross-functional team and abandoned mini-waterfall.  At that point, we thought we cannot become any more productive, but our productivity tripled, and other business units decided to try agile because our stakeholders were as satisfied as never before. It was not perfect and commitments were still occasionally missed, but we as a team – no longer divided into business and technology – were confident of our ability as a team to deliver high quality work while growing professionally and enjoying what we were doing.

This team-level transformation took us over a year, and now looking back, I realize that we made a natural move from agile piecemeal to a standard scrum implementation. While being able to realize some benefits right away, we were step by step implementing standard practices – stand up meetings, story point estimation, retrospectives – and moving towards Agile. Each step made us more successful, but only when we connected all the dots, we were able to see exponential growth of productivity. This reminds me of an analogy I came across in one of the blogs. Imagine you need to put a nail down. Take a hammer. Let’s say you do not see the value or just don’t know how to use the hammer. So you decide to decompose it into two parts. Now you can use a handle or the metal part to put the nail down, and either part is more effective than a bare fist. But only when you use the hammer as a whole the way it’s intended to be used, you will be able to achieve true efficiency.

Since this first experience, I worked as a scrum master on many teams, and finally moved to another employer and became part of team that is responsible for company-wide transition to agile. In my role of an agile coach, the first thing that I tell our teams is: Agile requires discipline, do not try to pick and choose until you master it well. Only then, you will be able to determine what sprint duration, what estimation technique, and team composition is optimal for your team. Follow Agile framework that you chose step-by-step, otherwise you will learn the value of Agile as a whole the way my first team did, through painful trial and error, through a “hammer” approach.

How to Hire a Good Scrum Master?

There is an interesting discussion in my linkedin group. The topic is: when you hire a scrum master, do you look for technical skills and leadership skills? Would team members respect a scrum master who is not a good subject matter expert or who is technically challenged? (in case of a software scrum team) 

I have seen so many team members who write great code and develop great applications, but fail in scrum master role when they choose to try it out. Similarly, I've see several effective managers totally failing this role because they did not have control over the team any more. So - while I prefer both - I vote for personal skills, leadership, honesty, desire to help, respect, unselfishness. In terms of hiring, there are situational questions that I find most efficient. Here are some examples:

1. An executive walks into your team's retrospective because he wants to know how things are going. Do you ask him out, and how?
2. At a demo, a business stakeholder not directly involved with your product, starts making suggestions like "why don't you change a label of that button" and "I do not like the color of this screen", and does this for each feature your team demo's. The team members look demoralized. How do you protect your team?
3. You are a scrum master for a new team that has no prior scrum experience. At a standup, two team members engage in a 5-minute long conversation on a specific topic. Do you interrupt them at the standup, right after, or wait until the retro?
4. At a retro, your team members do not speak up, while you know that there are communication issues on the team. How do you make them talk?
5. The team committed to 5 stories for this sprint at a sprint planning, but you know for sure they won't be able to complete all of them. How do you tell them about it so that they don't overcommit, and do you have to? 

There are more complex questions on managing cross-team dependencies, dealing with the business requests to deliver the product by a specific timeline, getting buy-in from the management, dealing with fractional assignments, etc. 

Any other ideas?

On Hyper-Productive Teams

As one of the ways to promote agile best practices, we established Agile Practitioners Lunch and Learn Events (APLLE) where teams share best practices, or teams vote for a topic, and one of Agile CoE members (which I am part of) provides an interactive presentation about. We take turns in being responsible for a specific APLLE event, depending on our own interests and areas of specialization (we are cross-functional, but we still have our roles within the Agile transition team). More about iour Agile CoE here: http://www.iliokb.com/2011/12/eat-your-own-dog-food-critical-to.html

Anyway, my next topic is on Hyper-Productive Teams. I did a lot of research. There are two distincts opinions:

1. This is all about having proper technology in place to allow teams be hyper-productive (automated testing, automated build, data virtualized, one-click deployments, etc.)

2. This is all about team building and healthy team dynamics (I love the "team building tree" metaphor introduced by Lyssa Adkins in "Coaching Agile teams").

So while I work on my presentation which will include both aspects, I can't stop thinking: is it people or is it proper tooling? What really makes a team hyper productive? Do you have any thoughts?

My PMI-ACP Exam Taking Experience

In today's competitive job market, primary credentialing is an important way to identify industry professionals with a full understanding and practical experience. It also a way for employers to identify prospective employees with valuable industry experience which is confirmed and verified by the means of widely accredited and recognized certification.

 This is one of the reasons the new PMI-ACP examination (http://www.pmi.org/Certification/New-PMI-Agile-Certification.aspx) released in 2011 raised significant interest in Agile community world-wide. As of December 2011, the following numbers on PMI-ACP examination were available on PMI community blog page and some other sources (http://agile.vc.pmi.org/Public/Community/Discussions/tabid/170/aft/9709/Default.aspx,http://thecriticalpath.info/2011/12/13/pmi-acp-numbers/)

•   7654 Applications Opened 
•  1404 Applications Submitted 
•  827 Exam Applicants Paid 
•  557 Exams Taken

In December 2011, when the results were releases, it was announced that over 500 of the test takers passed the exam. There may be several reasons for such a high rate. First, those who took the pilot exam were confident about their skills and knowledge, otherwise they would wait until the exam is tested and take this time to prepare. Second, PMI could be favorable to those who were brave enough to take the pilot despite no prep books (apart from the relatively large number of the books to read). These are my speculations though. Whatever it was, the exam is now released - starting January 31, it is open to all participants: http://www.pmi.org/en/Certification/New-PMI-Agile-Certification.aspx

My pilot experience is not fully relevant anymore. But here it is: 

I took PMI-ACP exam in November 2011 and I feel it has been a rewarding experience, which I am happy to share with you. First, I want to share that I embraced the fact that PMI acknowledged Agile by instituting this certification and while I’ve heard a lot of contradictory opinions on this subject, I felt that this exam is a bridge which will fill the gap between Agile and what we call “traditional project management”. PMI-ACP certification exam was welcome by the Agile community.

 Overall, this exam is an remarkable step towards bridging traditional, waterfall project management and adoption of agile practices. Many organizations in multiple industries are adopting agile practices to align their development environment to changing market needs, and with this trend, the requirement for project managers trained in agile practices is going up. In January 2010, Forrester release a research which shows that 35 percent of 1,300 respondents stated that agile most closely reflects their development process and made a conclusion that agile software development  processes, in which software is built in short iterations rather than mapped out fully in advance, have joined the mainstream of development approaches(http://www.forrester.com/rb/Research/agile_development_mainstream_adoption_has_changed_agility/q/id/56100/t/2).

The new PMI Agile-Certified Practitioner certification, PMI-ACP, reflects this tendency and addresses the requirement from project management everyday reality. Being an established project manegement boady with high value for the certifications it awards, PMI made this step towards recognizing the value of Agile practices. PMI established its Agile Community of Practice in 2009 and PMBOK^® Guide 3^rd & 4^th edition contain references to iterative development. According to PMI,

For practitioners, PMI-ACP^SM helps:

• Demonstrate a level of professionalism in Agile principles, practices, tools and techniques,
• Increase professional versatility in project management

For employers, PMI-ACP^SM demonstrates a practitioner’s:

• Knowledge of Agile practices, which shows the practitioner has greater breadth and depth as a project manager,
• Ability to lead basic Agile projects

 (http://www.pmi.org/~/media/PDF/Professional-Development/2011-EMEA%20REP%20Agile%20Presentation%20v1.ashx).

While I was excited about taking the exam, I was concerned with the fact that the questions and expected answers from PMI should not violate Agile values and principles. The concerns were triggered by two facts: first, PMI was not involved as an organization (according to my knowledge) in building Agile repository of knowledge so it is acquired methology rather than conceived and lived through; and second, since there is no AgileBoK (at least no single repository of knowledge on Agile), I was concerned about the level of consistency between 11 books suggested by PMI for preparation to this test.

Based on my exam experience, neither concern is in fact a concern for Agile community. I think questions adequately reflect Agile values (I am not aware who exactly was involved in creating the questions, but I certainly feel that exam preparers are Agile practitioners who share Agile values). And while there is certain degree of inconsistency (most obvious one is “Agile project manager”, “project leader”, and “scrum master”; or “team” refers to both “scrum master” vs. “team” and “srcum master and development team” in different questions – you would have to guess what is applicable) but overall, I did not come across significant inconsistency or ambiguity.

Overall, the exam experience was pleasant. I completed the questions in 1.5 hours and took another 30 minutes to go through those 20 questions out of 200 that I was not sure about. But let this not misguide you. This does not mean that exam is easy, though about 60% of the questions were quite straighforward, if you have significant Agile experience and have read the books from the list. You may not need all this time because there are no complex formulas or tricky confusing questions, but the level of knowledge required is adequate. It was not as difficult as PMP exam for me, which required a lot of preparation, but luckily, I’ve read most books on PMO list before PMI-ACP exam was introduced, so my preparation was reasonable. Again, it is hard for me to judge because I do not know the result yet – the results will be made available in early January (originally, it was reported to be Q4, 2011). While everyone would love to see results immediately after taking the test, I understand the reason why this is delayed and the fact that baseline has to be established before providing assessment. I find it thoughtful and support this decision by PMI, though I’ve read a lot from the disappointed test takers who were unhappy that they did not see the results right away. Pilot is a pilot though, and it will establish baseline for future test-takers.

Please note that PMI-ACP is not the only exam in the field of Agile knowledge. Scrum Alliance transformed the Certified Scrum Professional (CSP) program starting January 2012 by offering a 150-question exam, which is available at proctored test sites around the world and has a three-hour time limit (http://www.scrumalliance.org/pages/certified_scrum_professional). The intent behind the CSP certification program is to offer a clearly defined and well-respected credential in the Agile community, recognized as the primary credential for Scrum Professionals and sought by the employers who hire them. The beta test that was conducted in October 2011 to assure that the CSP examination met accreditation requirements and is theoretically and technically sound, and as of January 1, 2012, Scrum Alliance will be offering CSP as a credential that implies, regardless of the Scrum role in which an individual works, those holding it have a full understanding of Scrum and its implementation.

This being said, CSP certification deserves to be a subject of a separate review, and back to PMI-ACP exam.  For those of you who are planning to take the exam, below is my summary from the test I took in November 2011. While it would be unethical to list specific questions, I will list the areas and my not-so-accurate and definitely subjective estimation of the exam topics and what to pay attention to while preparing for the exam:

1.       Risk Management in Agile – around 10% of questions. This was not an unexpected topic (I read on linkedin that this area will be significantly covered but I was not prepared for the depth of questions asked). Make sure you understand risk burndown chart, have an idea on how Pareto principle applies to risk analysis, and how risks are managed in Agile vs. waterfall.

2.       How Agile delivers business value – around 10%. There were multiple well versed questions on the topic, many related to Lean but some to scrum (hopefully you understand the term “empirical process control” described by Ken Schwaber in “Agile project management with Scrum”). However, in some questions, the concept of business value (or “customer value” – these terms seemed to be used interchangeably) was hidden. Overall, there were multiple concepts tested, such as incremental delivery, time to market, and minimal marketable feature. Separate topic – EVM and measurements around customer value. If you read “The Software Project Manager’s Bridge to Agility”, you got this covered. 

3.       Agile values and principles - around 10%, according to my estimation, but these are difficult to estimate because all test questions relate to them and most were tested indirectly, e.g. the concept of sustainable pace or self-organizing team, however, there were direct questions on literal verbiage of those.

4.       Estimation and planning – largest group of questions, around 15%. Techniques – be prepared for terms like “Dephi technique” or “Monte Carlo analysis” – but if you passed PMP exam, you are most likely very comfortable with this terminology. Other questions were well thought-through questions related to who estimates and what unit of measurement is used with 2 or 3 specific examples where you will be asked to do iteration breakdown. Be familiar with the concept of progressive estimation. Overall, if you are practicing Agile and understand abstract nature of story points and the concept of velocity – and if you read Mike Cohn - you should have no problem with this large group of questions.

5.       Agile methodologies and relationship between them – another 15% or so. I had 5 or 6 questions related to Lean, one related to WIP in Kanban (very basic), and quite a few XP questions – on roles, principles, concepts. Interestingly, there were questions about relationships between those (scrum and XP or waterfall as opposed to Agile). Questions were not overly deep or difficult, but some were quite specific to the term or the concept.

6.       Roles in Agile – 10%. Multiple questions on roles – roles in Agile in general, in Scrum, in XP – roles related to specific ceremonies or artifacts, such as the “Definition of Done”. About 6 or 7 situational questions asking who is responsible for a specific artifact or who should take action in a specific situation. You should understand well when self-organizing team takes lead, and when scrum master is supposed to interfere to preserve process health – some questions seemed to be tricky – or maybe just deep and thoughtful. Pay special attention to roles in XP – there was a question about those which would be tricky, if you expected a scrum master to be one of XP roles.

7.       Behaviors and cultures – no less than 10%. I want to applaud PMI for having those questions. They relate to culture of transformation from waterfall to Agile, conflict resolution, proper behaviors in unwanted situations. I have to confess that I haven’t read Lissa Adkins’ book “Coaching Agile Teams” as part of my previous Agile life, but I read it in preparation for the exam and found it very helpful and informative. Highly suggest that you cover this material in preparation for the exam.

8.       Agile/scrum artifacts and ceremonies – another 10%. Multiple questions on burndown chart (including a practical question with a sample), two questions on information radiators, and – surprisingly – no single question on story (task) board – maybe I was just unlucky and did not get one picked. Multiple questions related to all Agile ceremonies – what questions are being answered, what’s the purpose and structure/duration, who participates, how is process enforced. If you read Ken Schwaber’s “Agile Project Management with Scrum” and if you are a Scrum practitioner – no need to worry, they are mostly intuitive.

9.       Resources – about 5% – multiple resourcing concepts related to team composition, dynamics, colocation.  Good questions provoking thinking – just one advice: be familiar with the concept of fractional assignments. I personally find it useful and was pleasantly surprised to see it on the exam.

10.   Communications – also around 5% - questions related to importance of face-to-face communication in Agile and techniques of working with distributed teams.  You would have to understand the concept of “osmotic communication” – almost everyone who writes about the exam indicates surprise that this not-so-widely-used term appeared on the exam – however, I agree with the choice of exam preparers because it is an important concept and one of success factors for Agile implementations.

My advice on books:

All the books listed by PMI is a cerefully made selection of the highly informative sources on Agile and it is important to read the all. Here are some sections to pay particular attention to:

·         From James Shore book, read about "fractional assignment", what they are, and whether it is advisable to have those in Agile.

·         Read Mike Cohn (both) and Alistair Cockburn - cover to cover on estimating and planning.

·         Michele Sliger - on risk management and EVM.

·         Lyssa Adkins and Ken Schwaber - make sure to remember specific examples because there are similar behavioral/situational questions on the exam.

·         Alan Shalloway et al. - on value stream management.

I read all books in my preparation for the exam, and as challenging as it was, it was a great experience to read and re-read them, and each one of them is a great book - informative and interesting.

And finally, if you are interested in expanding your Agile horizons, I want to add several books to PMI list that you will no doubt enjoy as much as I did (but most likely you’ve read them already):

·         “Scaling Software with Agility: Best Practices for Large Enterprises” by Dean Leffingwell

·         “Scrum from the Trenches”  by Henrik Kniberg

·         “Management 3.0. Leading Agile Development. Leading Agile Developers, Developing Leaders” by Jurgen Apello

·         “Agile Portfolio Management” by Jochen Krebs

·         “A Practical Guide to Distributed Scrum” by Elizabeth Woodward, Steffan Surdek, Matthew Ganis

·         “Practices for Scaling Lean & Agile Development: Large Multisite and Offshore Product Development with Large-Scale Scrum” by Craig Larman, Bas Vodde

Everything you’ve read above are my personal impressions from one instance of PMI-ACP test-taking based on my personal experience and perceptions. While I hope this will help future PMI-ACP test takers, please be aware that you will get a different set of questions/topics on your exam. Also, our level of experience may be different, so the items that seems either basic or complex to me, may be something different for you. My opinion is based on 6+ years of experience as an Agile practitioner in a scrum master as well as agile coach and transofrmation specialist role, prior PMP certified project management experience, as well as the books I read from the PMI list and beyond on the topic. As I mentioned, I am a member of PMI as well as Scrum Alliance and hold both PMP and CSM certifications. This review is independent and has not been reviewed or entitled either by any of those organizations, or by my employer.

I wish you all a successful exam taking experience.