we DO agile

Lessons on teams, tools, and projects. Not what the books say, but rather what the life dictates.

[wedoagile]

SME's Are Not End-Users

The other day I was struck by lightning while exchanging war stories with my professor and few active professionals.  We were talking about end-users and the point and intensity at which they should be involved in projects.  What was quite startling and made my hair go up in smoke was that most people did not even interact with end-users or they relied on set processes to dictate rather than elicit input. Furthermore, almost all were going on and on about the significance of SMEs while referring to the end-user interactions as either nuisance or a brief encounter.  

This alarmed me, honestly made my PM-ness boil inside! Based on my experience and observation here are few things that we might want to keep in mind:

1. A SME is not the customer. SMEs should not dictate what we are doing, but rather how we can do it. They can chime in, help with time estimates, dependencies, etc. Keep in mind that the end-user is not always an expert; their role is to simply use the system.  It’s a slippery slope; SME’s can get carried away with unneeded functionality which takes me to my next point…

2. Effectively delivering latent needs is a specialty, not the norm.  Only few companies are truly successful developing products/implementations based on “they don’t even know they want it” philosophy. Yes, Apple is one of them.

3. If you don’t have a buy-in from the end-user, you don’t have a product. Simple. Even if they use it from time to time, they will not support it, promote it, nor help you expand.

4. Ease up on the ego.  Most of us “think” that we know what features should be developed or how an implementation should be approached. Heck, I catch myself doing this too.  I eagerly explain my plan to the client, ready for them to gasp with pure amazement, impressed by my cleverness only to hear: well, that’s not going to work for us. We are different, so….

5. Remember, all clients say they are different.  Trust Maya Angelou and believe them because they actually might be telling the truth.  

6. Don’t assume. This is obvious yet so often forgotten. Even though you were right nine out of ten times there is always that one time that might cost you more than expected.

7. If you can’t access the end-user dedicate an advocate; someone who echoes their voice and vision. Again, this is not a SME, but rather someone who can help outline key functionality needs.

8. Don’t forget the “why”. Why are we developing this product? Why are we implementing this software?  This simple question often gets lost in the frantic do-whatever-it-takes situations.  Outside influences, opinions flying left and right, teams changing, it’s like swatting flies on a hot summer’s day (Shakespeare would be proud). Step back, catch yourself, and take a moment to remember why this project is truly being done. This can help you eliminate redundancy and maybe most importantly sift through those who should be bystanders vs. true decision makers.

[wedoagile]

78 Things I Have Learned in 6 Years of Agile Coaching | Rally Software Community

I have been an Agile Coach for over 6 years now.  I’ve learned a lot during this time, and I’m still learning. Here are 78 things I have learned so far:

What a great list!

[wedoagile]

The Ten Commandments [Working Agreements]

While attending conferences, meetups, workshops, and reading articles in the last few months I started to notice a common thread, two words thrown in here and there: working agreement (WA).

People sharing war stories, huddled in a corner, beaming with delight of how few simple rules brought their teams together. One person at the SCRUM conference mentioned having a “safe word”; his team decided on pineapple. Whenever someone was out of line or exuded negative attitude they yelled pineapple! Cute, funny and I’m sure shook things up a bit. Maybe it was the pineapple and my grumbling stomach, but I was hooked! Fascinated by it I started plotting my strategies for testing this in my life.

Here are some key principles I would like to share with you and hopefully save you few hours of reading and set you straight into action.

Here we go!

OK, tell me what a working agreement is?

Rules and behaviors that the whole team agrees on.  In laymen’s terms, what is okay and what is “not cool dude”.  Rules come directly from the team, not the team leads.

I also like to think of it as a cumulative growth approach, where you work on enforcing positive habits together rather than holding the fort alone.

Sounds cool, but we don’t have time for it.

Yes you do. This might be the one meeting that your team actually wants to participate in.  This should be fun. Approach it as if you’re a group of friends meeting for coffee and dreaming up the ideal strategy for starting a business together.

You can get it done in 30 minutes.  If it’s taking over an hour, that might be a red flag. Look for the reasons why.  Is the team arguing?  Is it getting too heated?  Is there one person who just won’t shut up? If that is the case, lack of time is the least of your problems.

How do I do it?

From reading multiple tactics I like this one the most:

Get together in a room, get some snacks/lunch and get comfortable.

Use a whiteboard; each person has to give at least two suggestions for improvement. Write it down on the board.

After everyone takes a turn, spend 10 minutes on pointing out obstacles from the last Sprint or project. Ask every person: What would you do to improve it?  Again, write all the ideas down.

Spend few minutes on voting. Each person should step up to the board and vote on their top three choices.

Isolate ten most popular suggestions and divide them into:

Behavioral rules, i.e.: don’t talk over each other; everyone on the team must participate in our meetings, start meetings on time.

Action rules for running the Sprint/project, i.e.: we meet every day for no more than 15 minutes, we don’t start vague stories, don’t code favors – if it’s not prioritized it’s not part of work, and so on.

Enforcing and the 10 commandments of the Ten Commandments.

Even though working agreements are owned and defined by the team and leads should not define the rules (that's an employee handbook), you still need someone overseeing the whole process. Without some enforcement and buy-in nothing will stick. Here are few tactics to try:

Check-in with everyone on the “rules” from time to time.

Be the one who enforces all ten rules, especially at first. Call people out.

During retrospective run a quick poll and ask if the rules work(ed), if everyone still is in agreement.

Once you see that some of the behaviors become second nature have another meeting and introduce a couple more.

Limit yourself, don’t define too many rules because no one will a) remember what they are, and b) the effort will be too overwhelming.  There must be a reason why they call it the Ten Commandments and not 199 rules for life.

Be careful with member isolation. Penalizing those who are not participating might be tempting, but you will get more results by rewarding those who are.  Remember, you catch more bees with honey.

Write out the rules and display in a visible place.  Make it fun, bold.  This not only will make it easy for your team, but might also inspire visitors.  People will start commenting:  What are these commandments on the wall?  What a great idea? I want to try it too!  You’ll see it will work like a charm.

Some rules will become invisible. Either they are too obvious or limited to infrequent situations. Remove and replace them with new ones. The key is not to add more to the list, but to keep the list concise and achievable.

Stay away from focusing on individuals, the WA is for the whole team. Respect is numero uno; never point fingers or push people away. Self-manage team means inclusive, not exclusive.

Relax and have fun. This one is more for me, as a type A personality I tend to take things a bit too seriously.  This is not about creating an employee handbook or having a nervous breakdown every time someone forgets a rule. The point is to create an honest and open environment of equality.

Why I like the idea of working agreements?

I love the fact that it bonds the team; it builds a tight-knit family, which is especially important in younger teams.

It allows you to put everything flat-out on the table, out in the open. Speak up, question it, and ask others.  It minimizes the silly gossip, which can quickly become a super-parasite!

It takes focus off of work and deadlines for few minutes, and instead addresses the environment and atmosphere.  Good energy, having a common goal creates a team of winners.  Bitterness and resentment will lead to poor results even if you have the best talent working with you.

Remember WA should help the team self manage and work in a more comfortable environment. This is not about adding checklists, spending more time in meetings or making everyone feel bounded by countless rules.  Au contraire! The point is to simplify, remove useless guilt, uncomfortable situations, and minimize conflict.   Don’t over do it, but at the same time stay focused on the goal and enforce what was agreed on. And of course, if it doesn’t seem to work – change it.

Good luck and have fun with it!

  If you want to read more on this I recommend:

http://www.scrumalliance.org/community/articles/2014/january/work-agreements-scrum-team

http://www.gettingagile.com/2008/05/02/creating-a-team-working-agreement/

http://www.uvm.edu/extension/community/buildingcapacity/pdfs/creating-capacity/working-agreements-defined.pdf

http://agilefaq.wordpress.com/2007/11/21/what-is-a-team-ground-rule-or-team-working-agreement/

http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&ved=0CEEQFjAE&url=http%3A%2F%2Fwww.pathsforall.org.uk%2Fcomponent%2Foption%2Ccom_docman%2FItemid%2C166%2Fgid%2C4%2Ftask%2Cdoc_download%2F&ei=wrjKU639NsuvyATSuIDwAw&usg=AFQjCNEbQ4Ff3_KwjIsFJyZgKBqTAiXlSA&sig2=WD6uDHopJ-WyZ8EpIJ6wFg&bvm=bv.71198958,d.aWw

[chrismurman]

Whether you are a team of one, or one hundred, we are presented with the daily opportunity to introduce positive change into our work environments. Asking tough questions is a challenge to say the least, but it is also imperative to foster growth in today’s climate. With teams somewhere...

[wedoagile]

The Power of Negative Thinking

Sometimes I feel stuck.  Trying to figure out where a particular problem may stem from, come up with creative solutions or calm the endless should haves/would haves in my head. This can be anything, team issues, stalling progress, missed deadlines, you name it.  I’m not referring to retrospectives, lessons learned; group meetings where we so often end up playing the blame game of us vs. them.  The after-the-fact analysis of what went wrong and why.  I’m talking about reacting in the moment when you’re stuck in the trenches, knee deep!

Here’s a novel idea to try:

Ask yourself:  how can I make things terrible right now?

And go do the opposite.

This comes from one of the more inspiring presentations at the ’14 SCRUM Alliance, where the speaker (Tim Wise from LeadingAgile.com) suggested a Negation Exercise - starting with the “bad” to get to the “good”.  During the session he led us through simulated situations, for example how can you make your paired programming partner miserable?  People shouted charming answers: don’t brush your teeth, don’t take a shower!  His intent was to apply the result for creating successful working agreements.  The idea of actually using negative thinking to my advantage really got wedged in my brain.  Piggybacking on the concept that we can only change ourselves and our own thoughts I decided to try this exercise on myself.  Of course, as with any new habit I forgot to do it first eight times out of ten, especially when I was emotionally invested in yet another blast of fire [issue] of the day.  Eventually though, in more peaceful moments when I could pay attention to my own thoughts I would ask myself:

When in a conference meeting: What could I say right now that would prolong this meeting?

Do the opposite.

When discussing project status: What can I say right now to ensure no one understands what I’m trying to communicate?

Do the opposite.

When with a client: How can I behave to make the client uncomfortable and lacking trust?

Do the opposite….you get the point.

I know what you might be thinking.  Why not just do the right thing from the start? Most people can differentiate between right and wrong.  Yes, that is true, but there is something magical in this negation process. It creates a clear boundary helping you color between the lines. Stating the obvious, most obnoxious reaction (as ridiculous as it may sound in your head) really helps to act from the purest, most beneficial for all intent. Doing “good” is not as good as doing the opposite of the worst action you can think of.  Of course, please try to keep it realistic and civil.  I don’t think there’s a need for stating horrifying, hurtful and primitive actions.  If that’s all that comes to your mind….oh boy!

I still only do this occasionally, when I catch myself, but I have to say that negative thinking concept sure turned out to be a pretty neat addition to my toolkit.

Good luck and happy experimenting!

  Tim Wise is an Enterprise Agile Coach at Leading Agile.

Blog: agiledude.blogspot.

Twitter: @timswise

[wedoagile]

A Roadmap for Agile Engineering @SCRUM Alliance 2014

[wedoagile]

Ken Rubin @ SCRUM Alliance

[wedoagile]

5 Traits of a Great Developer

This truly applies to us, not just developers.  Let's get to it!

1. Plain language.

Having some degree of interchangeable skills is a great trait. Being able to take a complicated or highly technical concept and strip it down to plain basic language will earn you gold stars.  This goes to many professionals, overusing fancy terms doesn’t magically give you an intelligent aura, I would say more of a jack$#% one. Less is more, plain and simple does the trick. People will appreciate and value you more for speaking in plain English.  Remember, experience and knowledge does not make you a better person, only gives you deeper insight into your specific line of work.  This leads to…

2. Don’t be condescending.

Everyone has a different role in your organization or team.  Just because you are a brilliant engineer does not mean that you are better than rest.  A great team is one where there is a complete set of skills and people work in unison. Don’t belittle others, make smart-ass remarks when being asked fundamental questions. One word answers are really annoying and only speak of you as a person, not your senior title.  Guess what? Maybe that “dumb” person has great skills and knowledge as well. This nicely transitions to the next point.

3. Listen.

Stop and listen to what people have to say. Sometimes we get carried away and get a bit too involved. It’s a good idea to sit back and open yourself up to new concepts, ideas.  Each person you interact with (not only at work) has walked unique trails, left distinctive footprints on their path. The vast levels of experience can truly work in your favor if you’re wise enough to see it. These different backgrounds, ideas, processes and tools can significantly grow your arsenal of knowledge and in turn shape your career. 

4. Speak up.

Now there is also the other end of the spectrum, the quiet, uninvolved individuals. Always waiting for others to make decisions, they simply want to know what to do and run to their corner, crank up their headphones and zone-out.  That’s nice and all, but I’ve got bad news for you, this will only take you so far.  If being a mediocre developer, team unit is your goal – keep doing what you’re doing. Just remember not to complain or feel left out when those around you seem to be moving forward.  An engineer who only quietly mumbles during the daily stand-up and tunes out others is just a warm body, not a team member. I understand, you’re shy. Not to seam harsh, but it’s time to grow up and develop some basic skills. You don’t need to be Fred Astaire-ing across the room, waving a fedora while rhyming your daily updates.  The bottom line is you are either interested in what you’re doing – or you’re not. If you don’t like what you do – change it. If you’re extremely shy and can’t manage to speak up or interact with your group, take baby steps and at least try.  Your colleagues will recognize the effort and reward you for it. I promise.

5. Mine and yours.

You get your user story and you run with it only to find yourself saying later: “Well you didn’t tell me that!”  The greatest users stories, tickets, documentation, boards need a dash of human thought (read intelligence and intuition).  When working on a specific feature ask yourself how it fits into the big picture. Consider the business need even if you’re all IT. The project should involve the whole team and relying on the Product Owner to define every possible detail/requirement is naive. Don’t just do what you read, always ask yourself – does this make sense?  This will save you time and potentially even save the project. Just because you work on a small piece/feature doesn’t mean that you should not be involved in the whole picture. It really is true, two sets of eyes are better than one. Think of the valuable insight you can offer.

[wedoagile]

20 Unusual Things 20 Successful People Do Every Day

Where success is concerned, sometimes the smallest things make the biggest difference.

[wedoagile]

Stop with the I!

    We all know those coworkers or clients who just rub us the wrong way.  There is something about the way they talk, demand or make us feel incompetent or micromanaged. Pay attention to their words, how they communicate tasks or voice opinions. 

Do they constantly say that YOU should do something, YOU should know this, YOU should answer that? Do they say I did this, I think that, blah blah blah   That’s the key, that “You” and  “I”.  Often that is the difference between a great team member/employee/leader and that jerk others just want to avoid. 

Personally for me, nothing made more of an impact on my interaction with others than introducing this one little habit, saying “we” instead of “you” or “I” as often as possible.  It’s so simple and so monumental.  So I challenge you to drop those dense leadership books and for one week and try this one tiny substitution.  Of course, I’m not saying that all the literature out there is for nothing, and I’m not saying that this is the answer to all your problems.  I’m only hinting that maybe some of the issues may lie in your approach. Yikes!   One week, that is all.  If you don’t notice a shift in the team dynamic then by all means go back to 182 principles of incredible team leaders.

I know, I know this is not that easy at first. Typically our jaws flap up and down before we can stop.  Trust me when I say that with some practice and self-awareness it becomes second nature. The point is not to sound like a crazy person and refer to yourself in third person, an overly excited camp leader, but to communicate in terms of involvement instead of isolation.

Let me give you an example:

Guys, your test cases must be done by tomorrow morning. Carol, you need to work on A, B and C.  John, you can take the rest. My reports are complete and I’m seeing too many errors in your validations. Why is that? Are you checking your work at all? Make sure to submit everything by 9?

Vs.

Hi guys, I have some news and it looks like our team needs to finish all the test cases by tomorrow morning. We’ve been working really hard, and hopefully this is the last cycle. We can totally do it if we share the load.  Let’s all focus on quality so that we can save our time and avoid re-testing. Carol and John, we have these tasks left on the table, would you like to divide them or work together?  What do you think would be the best way for us to approach this? Ideas?*

It’s all in the delivery.  The key here is to remember we are all human and we all want to do a good job.  Let people decide what the best way of doing things is.  If you need to make a decision don’t emphasize it’s coming from you, everyone should be involved. Best decisions stem from active teams. No one wants to work with a dictator, the morale and quality will drop so fast that you won’t even have time to say “I”.  Everyone wants to work with a pleasant person, one who is part of the game and not some outsider pointing out the flaws.

So wake up people! We live on this planet to be part of something bigger.  This is not just your game, your life, your job, your project.  Open up and look around you; whether you like it or not, you are part of a team be it at work or at home. The sooner you accept that you’re ONE of the players and not THE player, the sooner you will see amazing things happening around you. Just try it. It works like magic.

  *hello Agile manifesto point #1, people over process!

[wedoagile]

It is not my job to get the project done!

I’m preparing for a presentation – A Day in a Project Manager’s Life.  This might be a topic more on the PMI side of things, but it’s still worth raising.

Hi, I am a Project Manager and it is not my job to get the project done!

This is how I plan on starting my speech. I know – weird huh?

Imagine you are a traffic cop, directing the drivers, making sure that they don’t crash and definitely don’t kill each other.  Have you ever seen a cop get into a random car at an intersection? Better yet, the cop saying move over I will show you how to drive! I don’t think so.  I’m starting to understand more and more that I should be like that traffic cop, let it go, be calm and just guide people instead of getting my hands dirty and trying to fix every imaginable issue.   I do agree that it helps when a PM is knowledgeable in a particular subject matter, but I think it is much more important that (s)he knows how to help people. 

I think that it is not about leading, not about managing, but about helping people through:

1. Figuring out what they don’t know

2. Galvanizing them to wake up their passion for the project or at least make them somewhat interested

3. Navigating between team members and their skills

4. Reading people, knowing when to interject or step aside

5. Guiding in a way where all the ideas come from them or at least make them think that

And # 6. Confidence

I think giving people confidence in themselves, in the product, the endeavor, the goal…whatever it is you’re trying to accomplish is KEY. Everyone deep down wants to succeed – help them.

I understand that often this is easier said than done, but I am reaching out to those (myself included) control freaks who often forget that other people know how to do their job. Sometimes I really just need to let go and not feel so overwhelmed thinking that all the work that is NOT done is somehow my responsibility. You can call it ambition; I call it stupidity and ticket to early aging.

I catch myself spooning the work like pasta onto my plate and then hurryingly showing it down my throat (Wait, I don’t eat pasta – let’s use salad, with pears and walnuts and… darn! Off-topic). As I’m “growing up” I’m realizing more that it is just not worth it.  When I step aside and let other figure it out, when I don’t get anxious when things take too long I have more time to help others and to transfer my focus somewhere else and in turn accomplish more.

So, I raise this imaginary glass to you – the overworked, overstressed and overcommitted Project Manager and say RELAX.  There is only so much you can do. Your job is not to do the project work that is why we call it a team – and bless them!  Focus on making them feel capable and guide them to better solutions.  Does a coach run the race with their athlete?  No, because his job is to be on the sidelines checking the time, motivating and encouraging improvement.   Oh and let’s not forget, celebrating their job well done!

Cheers and Happy Friday!

[wedoagile]

Such a great idea - simple and so true.

[sourcetocode]

[wedoagile]

Are we Agile to be "cool" or are we Agile because it works?

At times I have a feeling that folks want to do Agile because it's cool and not because it makes sense.

The other day I heard a consultant asking for advice, her client wants to do Agile (notice I said "do" not "be") and here's the kicker - they want to do it because everyone else is.

Ha!

What a great way to run a business.  Doing something only so it looks good on a RFP and not based on an intrinsic need!

This will not let them slide very far and guarantees to put their associates through turmoil and high cost, especially where the company cannot be re-structured to allow for new processes (all off-shore development for one). Slapping on a label doesn't allow you to use the methodology at a full capacity and really benefit from it. This only opens up a floodgate of issues - think cost, low quality and chaotic management.

Yes, there are good ways of implementing Agile, but that is not the point here. Let's not get stuck here on a trend.  I think twenty years from now only true Agilists will stick while everyone else will go chasing something new. 

And from a business stand point, well maybe integrity, creativity and innovation should be the foundation (wait...did I hear Apple?) not Joe.inc next door.

...am I ranting? ugh!

I think it's really irresponsible that we are creating this "us vs. them" (traditional Waterfall) environment and we are missing the real objective here - do what brings best results for your company!

It's the same with a health regimen, just because it works for one doesn't mean that it will for someone else. Heck, if you're getting a thrill from walking for two hours a day don't go swimming just because you read an article! Soon you will quit all of it, throw your hands in the air and say:

See, I told you I just can't stick to anything!

Same here, people hear buzz words: Agile, speed, save money, faster delivery and they jump on it - except they do it all wrong, they forget to change their culture, way of thinking and process.  This is why you see people throwing their hands in the air proclaiming:

See I told you this Agile thing doesn't work!

Please, stop and think. Have a clear message, know your objective and stay true to yourself.  Reevaluate your process and truly ask yourself:

Are we Agile to be "cool" or are we Agile because it works?

[brecke]

Leading software development teams is quite different from just being part of one. You get to face new challenges and a whole set of work is expected of you, which you are not accustomed to doing. One of that challenges - and perhaps the most important one - is to get your team to dock onto a…

[wedoagile]

Kanban or Scrum?

Ever wonder...

When does it make sense to use Scrum over Kanban?

Hey, maybe I would be better off with Kanban?

Is my methodology really working or is there something better?

So, this morning I was trying to analyze my new projects, thinking that maybe if I employ a new methodology, use a different process I can streamline the process and well....make it easier to track and control.

And then a thought came to me....what if I use Kanban? Crazy, right? Maybe it would be a perfect fit since in my particular situation I pretty much know what is being implemented, what the end goal is and - well this is not about me or my projects; this is about the key characteristics, "decision makers": Kanban or Scrum?  Simplified, in plain English!

Here it is (and you're welcome):

Kanban - think well defined process, like manufacturing, assembly line, in and out. 

- You know what your input and output is

- There is a set process that you follow every time - repeat every time

- There is a well defined end result

- If you want to build a cookie cutter software - great! Use Kanban. If you want to develop an innovative cool product that evolves - don't use Kanban

- You can measure your past performance and track it over time

- Think complicated work where you need to define the tasks ahead of time and visually track them

- Think: hey guys, this is the work that needs to be done and here's the timeline!

Scrum - think empirical process, creative, lets evolve and develop as new requirements are uncovered.

- What process? We do something a bit different every time since each product (software/feature) is a new entity

- You adjust constantly, react to changes

- Since each product/project is so different it is hard to establish a solid measurement/baseline

- Think complex work; working in small increments where you continuously reassess whether you should continue with the project or re-plan

- Think: hey guys, they want us to create this, what do you think? Can we do it and if yes, how?

As for me, will I experiment with Kanban? Maybe - yet to be decided.

If you have nothing better to do and want to read more about this topic:

Kanban vs. Scrum

http://scrumcrazy.wordpress.com/2013/02/04/kanban-vs-scrum-kanban-is-not-for-software-development-but-scrum-is/?blogsub=confirming#subscribe-blog

http://www.infoq.com/news/2009/05/kniberg-kanban-v-scrum

http://blogs.versionone.com/agile_management/2012/01/06/1-kanban-vs-scrum-myths-hype/

http://blogs.versionone.com/agile_management/2012/01/06/1-kanban-vs-scrum-myths-hype/

[wedoagile]

Don't do it alone!

Funny thing how after every meet up I leave "full" as if I just had a really good meal.  It's not the sandwiches, sodas or pizza that they usually serve, it's the food for the soul.  Aww, I'm getting all cute and cheesy. The truth is that even though there always is a specific topic we discuss, being in a presence of like minded people, passionate, intelligent and engaged gets me tickled pink! I absolutely love how rational discussions on Agile practices are quickly turned into existential, philosophical debates. The thrill of being forced to over-analyze simple concepts, to think outside of the box, to get a glimpse of what other developers, engineers, testers, project managers, coaches deal with and how they respond to change (or don't) is a priceless experience.

I guess my point here is - go out, interact with your colleagues, with other people that you meet in (or not) your field.  As we all work with diverse teams and various projects, we can give back and share the knowledge, the lessons learned.  The smart ones will take the advice and learn from others' mistakes.  Don't isolate yourself, don't try to "figure it out" yourself.  In order to evolve and to stay passionate about what you do you must surround yourself with people outside of your day to day environment.

Go out there – don’t be shy!