Friday, December 28, 2012

Transparency - We weren't ready for that!

As many readers have experienced, working towards Agility is hard to do.

Many of us talk about technical details, process, C level executives, managers, change management, culture and a large variety of other things as to why becoming Agile is difficult for a corporation.


Perhaps the real reason is much simpler than we think --->  Transparency.


I believe it is possible that the reason Agility is tough to take in large corporations is Agile's approach to transparency.


Here are some examples (it is important to realize that in an Agile environment, all of the following examples might be very public within the organization).


  • The Product Owner does not know the value of the stories they are presenting to the team and the team rejects them.
  • The team realizes early on in a project that what they are delivering will give no value to the company and it becomes very clear the project has no ROI (Return On Investment).
  • The team cannot complete it's stories because it takes 3 weeks to get a user account on a server.
  • The team keeps track of interruptions and presents the information as a reason for losing 50% of their productivity (this doesn't include the cost of "context-switching").
  • The team reports that because of internal team member conflict (which they are working on), they estimate they lost 30% of this Sprint or Cycle capacity.
  • During the retrospective, the team has figured out that they have two senior level managers giving them opposing goals and report it as something they would like fixed.
  • The company is having problems with a product line and has reported to the team members they are losing market share.
  • There will be a corporate reshuffle and the team members are asked how they wish to re-organize themselves.
I know that there are many more examples that might come up for you.  Consider your own list.


I recall a comment from a previous customer who hit the nail on the head. He said to me after reading a published retrospective...  "We are not ready for this!"

I can't tell you how many times I've heard the phrases "Agile is about transparency", "We want transparency from the team", "We want to do Agile because we are looking for transparency".  Often the assumption is that the team is the one causing delays, acting improperly, slacking off, and the list goes on.  The common misconception is that transparency is only about showing what the team is doing wrong. 

Realistically, it is rarely the case that the team is the cause of all problems.  Of course, they may have some issues. That's part of being human.

What happens almost immediately during a new transition is that things start to become "transparent" and the real causes of delay start to appear.  This is immediately uncomfortable for people who weren't expecting it.  Perhaps in your case, the "transition" is only happening in one small part of the company.  Consider the effects of this transparency where it shows issues in other groups who didn't see it coming!

What can we do about this?  Why not warn them?  Why not give them some training and coaching?

transparency graphic
Why not be honest about the fact that the information coming out of the teams will at times be uncomfortable?

Please, take the opportunity to talk about Agile values in your corporations. If you do not know why Transparency is so vital, please seek out an Agile Coach, Mentor, friend.. Whatever it takes.


The Agile Manifesto has many references that would involve transparency such as "Business people and developers must work together daily throughout the project."  Previously, many problems would not have surfaced which this principle will expose.  

The Scrum Alliance Code-of-Ethics says the following ; "When we make errors or omissions, we take ownership and make corrections promptly. When we discover errors or omissions caused by others, we promptly communicate them to the appropriate individual or body. We accept accountability for any issues resulting from our errors or omissions and any resulting consequences."

OpenAgile has a simple idea about this. It simply indicates it's purpose as follows; "The purpose of OpenAgile is to create an environment in which people are free to express their true nature and capacities to contribute to the betterment of their organization."


By spending a bit of time on this, you can make your transition a bit friendlier.  Once people realize that transparency is expected and what it really means, the change will seem less frightening.

What's making it difficult for many corporations is that we haven't truly explained what will happen when information in the company becomes open and up front.

Remember, transparency is a two-way street!


by Mike Caspar
..........
References : 
Agile Manifesto Principles - http://www.agilemanifesto.org/principles.html
Scrum Alliance Code of Ethics - http://www.scrumalliance.org/pages/code_of_ethics

Sunday, December 2, 2012

Only one to choose - Choose the Sprint Retrospective or the Reflection and Learning Step of the Engagement Meeting


I've been finding this a recurring question for a while, so I thought I might share some thoughts on the subject.  People have been asking, if you can only do one thing from Scrum or OpenAgile, what would it be?

When deciding what the most important part of your Agile Framework is, think about the Retrospective (Scrum), or the Reflection and Learning part of the Engagement Meeting (OpenAgile).

This meeting is a focused way for an individual, team, community or system to improve through continual learning.

Many corporations who have adopted Scrum have started with procedural parts of Scrum such as the Daily Scrum or the Planning Meeting.  The teams "go through the motions", yet no significant changes are made to the way work is done.  Many team members simply don't grow as individuals this way.

Scrum's Retrospective Meeting is a meeting where team members focus on improvement of themselves, the overall system, or their processes.

Often, the results of the meeting are the discovery of system-wide obstacles. If adjusted, these changes will allow the team to work more efficiently.  Sometimes the meeting may simply expose friction between team members that needs to be worked on (not managed).

The OpenAgile Reflection and Learning Parts of the Engagement Meeting focus on learning about our environment, system, community, and each other. 

By focusing on increasing our capacity to learn, we allow ourselves to be open to new ideas and things to try in our global "system".  As a result, our ability to "be of service" to our community is significantly improved.

The words are slightly different but the idea is similar...

"Let's go back and look at the last period of time we worked together and learn from that.   Based on what we learned, we can do something different next time and see how that works out."  Improvement is incremental, not batched.


If you are a ScrumMaster, or Process Facilitator, consider doing things to make the Retrospective the most important part of your Agile Mindset.

This one simple meeting, has the ability to drive any framework, team, or system to improve quickly.  It also allows continual learning and improvement to continue.

If you really want to have some fun with the meeting as well, some self-improvements to consider includes reading Ester Derby's book, Agile Retrospectives: Making Good Teams Great or taking a course in Innovation Games.

For me at least, it's always great when this meeting is taken seriously by teams and by the company.  The leaps and bounds teams can make are incredible.  This is because they can quickly and easily see what new things they need to learn and what improvement they can make .. now.

Ignoring this important meeting is just way too slow.

by Mike Caspar

References : 

OpenAgile Engagement Meeting - http://www.openagile.org/wiki/Engagement_Meeting




Sunday, September 16, 2012

Extreme emotion can be normal during a change to high-performance



When an individual reaches a point where they believe they will have to leave an old idea behind to accept what you are teaching them, they can become very openly emotional.

It is very important to realize that some people will have exceptionally aggressive or antagonistic responses as you stretch their mental model of what they understand.

In many companies, should someone becoming emotional, it is somehow forbidden and considered a bad thing.  This response invokes responses from managers of "we need to deal with this problem".

I find this intriguing.  For those of you that are trying to change mindsets away from a command and control environment to a self-organization model, I have some thoughts for you to consider before thinking that something has gone wrong.

All individuals have different knowledge and experiences to drive their ideas. Consider, that for many, they may have only experienced one company and one way, for much of their working lives.

When someone comes close to the edges of the box that makes up their knowledge, it can be common for them to realize they are coming close to a point where their “original” ideas are at question and they may have to leave them behind to move forward. At a minimum, some of those ideas will now be in question.

Previous ideas are a very big part of a person's reality, and has brought them through life to this point.  A new idea does not mean a person needs to abandon previous ones.  The new knowledge needs to be in addition to what they already know.



Remember; What the person knew before was not incorrect.


OpenAgile specifically addresses this by focusing on Learning through it's "Learning Circle" as part of the core framework.


Scrum allows learning through the effective experimentation of a team to try and accomplish and deliver a sprint goal and reflect on the results.


Other frameworks allow learning through constant experimentation and continual improvement.


An environment of trust is absolutely mandatory for this to happen safely. Trust in the team member and trust that the organization will act responsibly while the team member is in the vulnerable place are mandatory.  Without trust, many Agile frameworks will eventually fail.



Emotion can be high when coming out of  a "Mental Box"

If you are trying to help someone to learn something new, remember that extreme emotion is not always bad and is something you should expect.  Extreme emotional outbursts may mean you are making progress.

I think back to when I was a flight instructor.  As part of training, I would push people to the limits of their comfort levels and understanding. They were of course, willing participants, which is important to point out.

There were some parts of flight training that were frightening to many.  The learning was all fine until we would head out into the air.

When it came time to push them-selves to actually use this knowledge, often very abusive and aggressive comments would come from them. They were finally going to cross over the barrier to a point where they knew they would have to leave their old perceptions behind.    

As an instructor, I would allow them to vent, get angry, yell, or even in one case, punch me in flight.  

I learned that when a student reached that “final moment” when they would leave their inhibitions behind and move over the edge to do what they knew they would need to do, they would sometimes be very dangerous.  I learned how to defend myself in the event a student could not take this final step. 

I once had a student reach across the cockpit and put me in a headlock just as he changed his mind immediately AFTER we started to Spin*. Needless to say, this was frightening for the student (and for me!).  

When this happened, I could not panic.  I took control, recovered and allowed the student to talk it out for a bit.  He wanted to try again.  It took about 15 minutes of just flying around looking at scenery until he made the decision to try again.  He eventually did the spin. He is now a proud private pilot who owns his own plane.


After taking that step to realize the old ideas would not allow him to grow, he opened his mind to learn everything there is to know about the new. This is a truly rewarding experience for both the student and for the instructor.

When you are working with managers, team members, executives, project managers, CEOs, CIOs or whomever, remember that when they become very antagonistic and very angry, this may be a sign that they are realizing they are simply reaching the end of their “mental box”. An emotional reaction is a natural, human self-preservation instinct kicking in.

Don’t let it phase you, and most importantly, just be patient and let them work it out. Make sure their past knowledge is considered valid.  That knowledge can be built on.  It is not to be destroyed.

They will either cross or not-cross that barrier. This is not under your control.  It has to be truly up to the person reaching that point.  

For me at least, I find that if someone has finally reached the point where they are becoming aggressive and nasty about their ideas, this can be a good sign.  

Please note, in some cases, the person may just be reaching that point where they will "submit".  This is not a good place to be.  The signs and reactions are similar, so please be careful.  Make sure the individual is willing to participate in the knowledge transfer and growth.


Not everyone will cross over their barrier.  For many people, the past ideas are just too powerful or the person does not feel sufficient trust to allow them to take a chance.

Whether it be the idea of "command and control" vs "servant leadership", or the concept of "working for the team" vs. "working for myself", there are some pretty serious emotional barriers to cross when transitioning to an agile mindset.

I remember having a discussion a long time ago with a very successful businessman called George R. We were discussing what makes or breaks entrepreneurs. He told me "What holds people back is the fear of loss”. It has stuck with me for life. 

This can apply to fear of losing physical possessions of course. It is important to realize this can also apply to ideas.  

Whether you are trying to change and organization or simply help someone learn to work in a high-performance team, remember that many standard “self-preservation” responses are a good sign that you are making progress.  Don’t fear them.  Above all, remain patient.

I know the instinct when we see upset people is to assume we have done something wrong.  This is a normal response and might indicate you are simply doing everything correctly.

Good luck.

by Mike Caspar

References :


Spin - What is a Spin

OpenAgile - http://www.openagile.com
Scrum - http://www.scrumalliance.org  / http://www.scrum.org
Command and Control  : Wikipedia
Servant Leadership - http://www.greenleaf.org/whatissl/
Self-Organization :  Wikipedia

Sunday, September 2, 2012

VS2010 DBML inadvertently helping teams learn to check in code more often

An important part of development in a team based setting is the ability to quickly and easily check in your code, have it built with something like Jenkins, Cruise Control, Team City or Bamboo, get quick results about the compile, integration tests, unit tests, and so on.  The results need to come quickly to be of any use.

I have seen .NET developers who are new to the ideas have trouble with the concept of writing small bits of code, making sure tests pass and then pushing them to the source repository in small batches (commits).  I should mention, this habit is not restricted to .NET developers only. This is just the topic of the post.

The habit seems to be to work all day then try to do a push at the end of the day.  This can cause some significant merge problems and inevitably, defects during the next compile/build/test cycle.

A team member will pull the days' changes into their workstation and find that nothing compiles.  This problem eventually turns into a habit of doing the end of day commit an hour before the end of work to deal with the likely problems with the merge.

Sometimes, this results in many hours of work being held off "for now" because it is simply too difficult to merge.  The team develops an attitude of "we'll figure it out tomorrow".

In Visual Studio there is an interesting "feature" for managing database interaction called DBML.  DBML is sort of control file or schema mapper to allow .NET developers to easily connect to data using one "connection container" or "data context".  I am sure there are some technical deficiencies with this comment. That's not the point of this post.

A team using the DBML concept will find that the longer they wait to push their code, the worse their problems will be.  The DBML is built in small little cryptic pieces (to the human eye) and becomes almost impossible to merge if two team members have changed it locally.

This means that when you attempt  a merge with Git, Mercurial, SVN, etc., you will find that you will have no choice but to basically keep one person's changes and tell the other person to start from scratch.

If you are in an environment where large amounts of data access are happening and your team is using DBML, you will be constantly changing this file and having merging problems.

Because of this quirk in VS2010, I have seen a team implement a rule "Whoever checks in their code first wins during a merge conflict". The result of this rule is that developers end up checking in often and in smaller batches to ensure their work remains the "keeper" during a DBML merge.

What I find intriguing is that this quirk is inadvertently changing the habits of .NET developers who used distributed repositories to check in their code on a more regular basis.

Mike Caspar

References :

Jenkins - http://jenkins-ci.org/
Cruise Control - http://cruisecontrol.sourceforge.net/
Team City - http://www.jetbrains.com/teamcity/
Bamboo - http://www.atlassian.com/software/bamboo/overview
DBML Format - http://msdn.microsoft.com/en-us/library/bb882675.aspx





Sunday, August 26, 2012

Does becoming Agile require Culture Change?

Recently, I have been seriously considering the question of Culture Change in relation to Agile. 

Please consider this example and decide for yourself.  Does this example require culture change.... Yes or No? 

The scenario.

An important part of many Agile frameworks is the concept of the team working on "the most valuable work" for the company or customer.  Another fundamental component is the importance of truthfulness.

You are working with a team that has discovered and acknowledges that the project they are working on will have little or no value to the company when they are finished.  When the project was conceived it made sense.  It no longer does.

The team does what they are trained to do and brings that information to their leaders.  The executives and managers, after carefully reviewing all the facts realize this is true and the project is terminated.

Praise is given and the team is moved on to the next project in the huge list of backlogged projects.

After a few cycles, iterations, sprints, cadences (depending on your preferred agile framework), the team realizes the same is true for their current project.  The project is again cancelled.

As a result of the cancellation of the two projects, several managers will not reach their department objectives for the year and therefore will lose bonus money.

End of Scenario.

Is the team successful?

Is the team successful from an Agile perspective?

If this happened in your organization, what would happen?

What needs to happen to allow the team to do valuable work?

Is a Project Management group being rewarded for finishing projects without consideration for corporate value of the projects?

Are teams rewarded for acting with integrity?

Are managers and executives rewarded for acting with integrity?

Are teams rewarded based on achieving results?

What if those results are no longer appropriate?

Are teams rewarded based on learning and improved capacity to handle future work?

In your own opinion, if the answer to these questions doesn't match your ideal, do you think that you will need to change culture to achieve your perfect answer?

More importantly, do you feel that your corporation wants to adjust what you have discovered? Why? Why not?

I personally think we need to consider this type of situation when deciding if becoming Agile requires culture change or not.  

I put this out there as a question to ask yourself for your own environment and reality.

Happy pondering.

by Mike Caspar





Thursday, August 9, 2012

Information Radiators and the Vogons!

I recently had an interesting discussion with someone while trying to go over the difference between an information radiator and an information refrigerator in an Agile context.

Providing visible and public information to the stakeholders and the company is an important part of Scrum, OpenAgile, or your Agile Framework of choice.

We were discussing the fact that their system where everybody diligently enters all their status updates, burn-down info, obstacles, and so on isn't seen by the Stakeholders or the rest of the company.  The information doesn't serve the intended needs because the stakeholders use a different system to receive updated information.

Then, it came to me.... Think about The Vogons!

In the book, "The Hitchhikers's Guide to the Galaxy", the Vogons are clearing a path through space and destroy Earth to make way for an intergallactic freeway.  Arthur Dent (the human in the story) is outraged that there was no warning before his planet was destroyed.

The response from the Vogon Commander is something along the lines of ..  "It was on display in the bottom of a locked filing cabinet in the planning department in the basement."

The Vogon commander implies that the information was communicated and that it was not the Vogon's fault if Earth didn't do anything with the information.

Make sure you are not a Vogon.  

Just because you post information into a Wiki, Tracker or electronic tool does not mean you are radiating information.

You may be putting information in the system in a format your group can retrieve or see, but that does not mean it is reaching your stakeholders.

Consider letting your stakeholders know what you can provide and then ask them what will help them easily see it.

Mike Caspar

References:
SCRUM - ScrumAlliance.org, SCRUM.Org
OpenAgile - OpenAgile.com
Vogons - Hitchkiker's Guide to the Galaxy






Saturday, July 14, 2012

A short story about Acceptance Criteria and a medical procedure to help your Agile team

I recently made the following post on AgileAdvice.com where I guest post occasionally.

I believe this topic can help many teams, so I thought I'd put a link there for those of you that are interested in thinking about Acceptance Criteria.

Here's the link.... http://www.agileadvice.com/?p=1991

Mike Caspar


Saturday, June 23, 2012

What's in it for me ? It doesn't hurt to put yourself in the other person's shoes.

I have been noticing something when talking with some fellow Agile coaches, and wanted to just pass along a "thought".

Although we cannot always provide an answer to the question "What's in it for me?", when we're talking about an Agile mindset, often we can and ignore the opportunity for an easy win-win situation.  This just requires a bit of a step back from being and Agile Evangelist, to thinking about change initiatives and how knowledge about that topic can help.

A good friend and Agile coach recommended a book by Kotter recently, focusing on organizational change. It got me thinking about myself and how I approach change.  A reference to the book is at the bottom of this post.

Ask yourself, "When I tried to explain the Review Meeting to that executive VP, did I talk about the process of how the meeting works or did I talk with them about how that meeting can help them?  Did I let them know what information they could learn from it, how they could achieve future vision, how they could make strategic plans based on the input and feel like they really know what's going on in their companies ?"

If you're like me, you've often gotten trapped talking about the meeting instead of the intended results.  I find that if I pay attention for cues in the conversation, I can usually catch myself if I'm careful.

When discussion Scrum's Review Meeting with an executive, if I hear myself say something like "the meeting works this way", I trigger myself to say.. "HEY, wrong conversation... that's for training... we're not training here.".  Think about your target audience (your customer).  

I then take a DEEP BREATH, ask the person I am talking to for a moment or a quick break.  I may even say, "Mr or Mrs. Smith, please bear with me.. .I've gotten off track.  I'm not providing you information that's really useful to you.  I will be back in two minutes after I clear my mind.  I want to give you information that is useful to YOU... That's more important to me.".  Be honest.  After all, you're human too.

Many of us find ourselves in situations where we are talking about how Scrum, OpenAgile or any of the other Agile Frameworks work.  We will also be sharing information with C Level executives who are seriously interested in learning more.  


The ironic thing is that many of us talk about how Agile is not about process and is about culture.  Then, when we have the first opportunity to talk to an executive, some how.. many of us end up talking about Process.. .What gives?  


This might be an interesting discussion for another post.  I think it might be related to the USUAL questions asked by a C Level Executive.  We are the ones who need to break our habitual answers.

There is a multitude of sources of information about how change works.  One part of most change initiatives is to put yourself in the other person's shoes and ask.  If I was them "What's in it for me ?". Better yet.... maybe ask them!

Granted, there will not always be something in it for them. It may just require sacrifice.  Nothing is perfect. 

Also, urgency for change has a big impact here and cannot be ignored. 

I find the majority of situations have something in it for the recipient of a request for change.  It seems pointless to me to throw away this 'gift' of a win-win by ignoring the possibility.  

As always, comments welcome.

Mike Caspar


References:

Wednesday, May 23, 2012

The importance of the Primacy Effect for learning



I recently attended the Scrum Gathering 2012 in Atlanta.  During the gathering, there was a great Keynote from Clarke Ching.  The theme of his talk was "Focus".  The second part was “Multi-Tasking is evil”.  During the keynote, I noticed that Clarke used the Primacy Effect for his keynote and was intrigued.

Primacy is something I learned about as a flight instructor and is a mandatory concept for teaching others to fly in Canada.  It is important that we use the Primacy Effect to teach both ground schools and the in-flight lessons.  The more complex the topic, the more important this is.

I realized that same knowledge and experience from something that teaches complex decision making skills required to fly could be used when giving lectures or teaching where we want to show positive and negative ideas or concepts. 

From Wikipedia: “The primacy effect, in psychology and sociology, is a cognitive bias that results in a subject recalling primary information presented better than information presented later on."

In flight instruction, we are concerned about “initial” impressions and ideas (what goes into the brain first).  Often during a crisis situation, reversion takes place and the first learned action or idea is the one that overrides.  Therefore, if we’ve taught something with the “undesired” behavior or idea first, this could be potentially dangerous.  During stressful times, the default decision making is to use first learned knowledge as the brain processes ideas.

Don’t get me wrong here.  I am NOT suggesting that we should be deciding what is right and what is wrong.  This is FAR from the intention of this article! I am trying to give thought to teaching style for right and wrong type demonstrations, exercises, and teaching. 

I’ve seen many people say “don’t teach people right and wrong", yet still spend an hour doing a presentation to “prove” their “right way”.  Sometimes we find ourselves in a position to demonstrate or show two sides during a discussion. 

Many of us come from a “problem solving” mindset.  We feel a need to show the Negative activity first and then to “demonstrate” how much better it could be the other way.  We show or call out the problem, and then we then show the “better” way.  

The example used during the gathering was a demonstration of how multitasking could change simple tasks into complicated ones.  Quality was significantly decreased and the exercise was very stressful when done the “difficult” way.  Actually, even without the Primacy Effect, I think the learning went better than if the exercise had been done the other way around (my personal feeling).

Clarke made the decision to show the “Easy way" first and allowed the audience to do that first (Primacy).  He then showed what would happen by allowing the audience to do the exercise while multi-tasking ("Hard way").  The effects were dramatic.  The second round was noticeably more difficult than the first.  

By following the concept of the Primacy Effect, the “non-multitasking” option was entered into the mind first and would have to be “unlearned” first to switch to the non-desirable multi-tasking mode. When I personally think back to the exercise, I remember the first method.  I then search my memory for the second, not so easy way.

If you are doing a keynote or training a concept where you are trying to demonstrate a “right and not so right” to make a point, CONSIDER the idea of Primacy Effect to encourage better learning.

I acknowledge that sometimes you just have to put a big pile of problems there for someone to see to fix them.  I have to ask, what if you taught the smooth way first and then showed what would happen if you did not do that?  

If you have taken it upon yourself to “teach” a concept with your perceived right and wrong, then perhaps you might consider teaching your right FIRST, and then move to the anti-pattern(s) afterwards. 

I consider it to be more respectful to learners to go through what you think is correct first, and allow them to recognize the “wrongs” for themselves.  Perhaps, if you present the ideas to the students as something to think and talk about after the initial training, it might be more appropriate.

Trying to “hide” the “right” way you intend on miraculously sharing with them does not really support the idea of the Primacy Effect.  

I have regularly heard other agilists mention the "habit" of managers and team members during a crisis.  Perhaps the root of these habits is how the behaviors were originally presented.

Of course, everyone should do what they feel comfortable with.  I present this simply as an option for those of you who might be having trouble to get your ideas and concepts to “stick”.

I also wanted to thank Clarke for a great discussion about this idea during the conference.

Comments always welcome.

by Mike Caspar

References : 

Clarke Ching – http://uk.linkedin.com/in/clarkeching
Clarke Chings' - The Agile Experience: Multitasking Is Evil (which is not how he did it in Atlanta :->)
Primacy Effect - http://en.wikipedia.org/wiki/Primacy_effect#Primacy_effect
Transport Canada Flight Instructor Guide (PDF) – https://www.tc.gc.ca/media/documents/ca-publications/tp975e.pdf  (search for Primacy)


Sunday, May 13, 2012

Is Communication the correct word for Agile in the Enterprise?


I was recently in a discussion with some folks where the topic was the acceptance of Agile principles by managers and employees.  Several times during this discussion, "communication" came up in the context of letting people in the organization understand why they were going through an agile transformation.

A manager in the meeting made the following comment;  "We have emailed, had meetings and told everyone why we are doing this.  There will be no talking to them and asking questions from them about it anymore.  That would be a waste of time.  We have communicated with them already."

An enterprise does not necessarily have the same meaning for the word "Communication" as many of us might think.

When discussing Agile teams and projects with stakeholders, I often will say (I think incorrectly) something such as "An important part of your agile adoption is communication."

I recently realized, I may have been using the wrong word when discussing human interactions in an enterprise.   Perhaps the correct word should be "Dialogue", "Conversation", or as the agile manifesto simply put it "Interactions".

Often, large corporations have a separate "communications" department.  In some cases, there may be an entire division just for "Communication".  These folks have some very specific ideas of what communication is.

Communication
Communications has a responsibility to let employees know about new company initiatives, plans and direction.  They have a responsibility to do Investor news reports, company news for the press, and a variety of other messages.  Think of it as Outgoing Communication, or something with a sense of being Finished.  It has been communicated.... Period.

Don't get me wrong.   I've talked with many people in Communications and they are definitely folks who care about the feedback loop.  Occasionally, they may even get to do a survey, or if they are lucky, some focus groups.  Unfortunately, like other industries, they often don't get to do what brought them to the field in the first place.

Perhaps, teaching people in Communications about agile would serve an organization well.  In fact, I know they would really appreciate the incremental feedback loop. Maybe I'll discuss that in a future post.

When talking with stakeholders, we should stop saying that a fundamental part of agile is communication, and instead say something like, "For an agile adoption to be successful, it is extremely important to keep interactions between customers, managers, and team members active and alive".

The point here is that Communication is not what's important to emphasize.  It is dialogue, interaction, conversation, discussion, talking, chatting, collaboration or whatever word you want to use.

The word "Communication" has a very specific context in an enterprise...Use with caution.

Mike Caspar


References:
agile manifesto  - http://www.agilemanifesto.org















Friday, April 27, 2012

All the learning is useless without one thing.....WILLINGNESS

A very short post today.....
All the blogs, courses, conferences, manuals, videos, presentations, conversation, guidance and training about Agile are all useless without one thing....
WILLINGNESS

Webster's defines Willingness as "The quality or state of being willingfree choice or consent of the willfreedom from reluctancereadiness of the mind to door forbear." or "cheerful compliance"


WILLINGNESS seems to be directly related to answering one question.... WHY?


Without addressing WILLINGNESS to Learn, Change, Adopt, Learn or even Listen, it is all pointless noise.  


Ignoring Willingness is foolish (a.k.a. Change Management)


Mike Caspar


Comments welcome.
(moderated only for Spam).


--------
References : 
Willingness Definition : Webster Dictionary On-Line 



Thursday, April 19, 2012

Planning Poker Cards For Estimating Projects


A post at AgileAdvice.com with an idea about using Planning Poker Cards to estimate larger amounts of work (projects)...

Planning Poker Card Values Transformed

"Nothing fancy, works quickly, and gets everybody thinking about the big picture."... more


Thursday, March 29, 2012

I am a Business Analyst. Where do I fit on our Scrum team?

Recently, I was chatting with a team member on a newly formed SCRUM team.  Her background is as a Business Analyst (BA).  They are not a customer of mine, just someone I know going through a transition at their company.  I'll call her Sally.

She was concerned that she didn't know if SCRUM was right for her because "In SCRUM there is no Business Analyst". Sally "didn't want to become a developer.  There is too much of a skills gap".  Her words, not mine.

I thought I'd respond to her here and perhaps share some ideas for others that might be going through the same sort of question.  Maybe these ideas will work for you or maybe not.  If more than one person can be helped by reading this, then great.  It's just food for thought.

On a SCRUM team, team members are expected to work on Stories (a piece of functionality or value for the company or customer) as a team.  This means that everyone pitches in to complete tasks to finish the story.  YES, this means you will need to learn SOME development skills. The reality is, if  you're truly working WITH the team, it seems highly unlikely that you wouldn't learn something, just by proximity and osmosis alone.

What should be said though is that if you feel that being on the team means you will become a developer, something is missing from your environment.  The team should be cross-functional.  This implies there are people with different backgrounds and skill-sets coming together to try and deliver a Potentially Deliverable product each Sprint.  It also implies that team members learn more about each other's skill sets.  This to me at least is part of the fun of being in a SCRUM environment.  I love to learn.

You (as a BA), help the team in many ways.  Firstly, you have a natural ability to notice that what is being created is not what the "customer" is looking for.  On an Agile team, you don't need to wait until the entire Sprint is completed to recognize this.  Your abilities are vital during Sprint Planning, during Grooming and during the complete development of every story.  You are a very important part of the product delivery.

As you are working on these stories together as a team, you have the same level of input into the stories as any developer on the team.  You need to be asking yourself, "Why is my team not working on stories together as my input is valuable?" Talk to your team about this.

There is more to software delivery than just writing code.  Agile Testing is a form of QA (that is imperative to successful delivery) and is actually closely related to your existing mind-set.  Perhaps you don't have the technical skills in that area today, but you'll soon discover that if you take the Testing position seriously, it can be more like what you naturally do as a BA than you might expect.

Yes, there are some specific skills to learn (some which might require some development type knowledge).  Professional QA is a career in itself.  I don't want to lessen QA career skills here, just trying to help with a possible solution for you.  The key here is for you to learn this WITH the team's help and for the team to learn from you.  You are in it together (or should be).

As a SCRUM team member, you still need to want to learn the skills of the other team members to become a more rounded person.

However, I  know that even if I spent a year in design school, I would still be just an OK graphics designer, and not an expert.  It's just not in me.

That being said, I still learn what I can about it. I have learned for instance that I should not leave only a 10% space at the top of the page without talking to the graphics person on the team BEFORE I decide to do that.  I have also learned that I should not assume that the page will be white and design everything up front based on this.  This is why we should work TOGETHER.

In a pinch, I could probably pull of reasonable graphic.  I wouldn't be afraid to do it if it was left as a task on a team I was on.  For me, at least, this is part of the fun of SCRUM.  I needed a graphic for this page, and managed to make the graphic on the right :->

Generally, when people say they don't want to try new things, it is because of their Environment, not that they don't want to learn.  This is where you should have your Scrum Masters and / or Coaches help the organization to change to give you the ability to feel comfortable with experimentation.  Experimentation and learning from mistakes is very important to becoming exceptional team members.  You need to be able to learn new things and inspect the results as a team.

Sally, I know you have a passion to help the customer and listen to their needs.  This is ideal for a SCRUM team.  The customer is a VERY important part of the process, and no amount of teamwork will be worth it if the customer won't or can't use the product when the team is done.  This is why there is a such an aggressive requirement to have the Product Owner or Customer's representative there during the very quick development cycle.

Sally, you've told me that the company has not agreed to provide Q.A. people for the team.  As you mentioned, the team is sharing this responsibility.  YOU however, have some very special skills that you already possess; The ability to see the customer's viewpoint.  This is invaluable to the team.  In a SCRUM team, "QA" or testing is a CONSTANT part of the process, not something that happens at the end.  Every screen, every bit of important logic, should be considered from the perspective of testing, both technically and from the user's perspective.  A development team member really shouldn't be writing logic without discussing it with others on the team to make sure that it can be tested and that it makes "business sense" as well.  Think of usability for instance and it's importance.

You already have the goals and aspirations related to quality for the customer.  It may be a natural fit for you to think of yourself as an Agile Tester and learn more about it.

In the book "Agile Testing, A Practical Guide for Testers on Agile Teams", Lisa Crispin and Janet Gregory have the following to say about Agile Testers;
Agile testers see each story or theme from the customer's point of view but also understand technical aspects and limitations related to implementing features.  They can help customers and developers achieve a common language.
Hmm.. Sounds like how BA's think to me.

As your team gets faster (if they work as a team and not individuals), they have the ability to create software Really, Really Fast.  Without the QUALITY part of the equation, your company risks making lots of BAD software, Really, Really Fast.

Since you find yourself in this position, why not consider learning more and just "assuming" the responsibility of improving QA practices on the team (with them knowing so of course).  You already have the emotional desire to think about the customers' desire for quality.  You obviously have SOME technical skills.

This doesn't mean you should be the only one on the team doing this.  Quality is still and should always be a complete team responsibility and you shouldn't become the only person who cares about it on the team.

Testing and the testing mindset is a very important part of software development.  QA professsionals will learn a bit about coding and coders should and will automatically learn about how to think more like a tester.

So, although you have some problems on the team, YOU have the power to work with your team to help yourselves out.  You've told me the team needs QA , and that you all recognize it as an impediment.  This has been going on for several months.  Clearly your management is not listening, which is truly sad.  Perhaps instead of you being frustrated, you could just start to do something else to help the team out.  Try out the book "Agile Testing from Lisa Crispin and Janet Gregory", and see if it inspires you.  Perhaps, try one or two of the ideas from it.  Maybe you'll surprise yourself how much you like it.

Yes, you will still do some occasional coding, but there's NO WAY the team should be delivering software that hasn't been tested at all during development and without the benefit of someone thinking about the customer's view-point from a technical perspective (someone like you are).

Another alternative for you is to pursue the Product Owner role in your organization.  That might work for you as well.  This would be up to you.

After you've tried all these things, you might still find that SCRUM is not for you.  No one ever said it was for EVERYONE, though a team of only pure development really isn't a SCRUM team either, which might be part of your frustration.

You should give yourself a chance to learn the "Agile Tester" idea and see if you can help your team out that way.  The team, and the company should really appreciate it, and you'll have learned some new skills, which could never hurt you :->

Maybe you'll even discover a whole new career path you never saw before!

You're in a big company.  If all else fails, you could always go to a non-Scrum team, or migrate into the Product Owner Role somewhere.  Your company is big enough that you could easily do this.

Another thought, though not pleasant; you MAY be holding the team back by not embracing the idea of cross-functional work, especially if they are all prepared to so and you are not.  I don't believe that's where your mindset is, but I needed to mention it.  If you simply don't want to work with others, learn and share with others, no amount of reading, practice or coaching will change that in you.

Anyone who tells you that Quality and the customer isn't an important part of SCRUM, is seriously missing the point. It's about delivering VALUE.  Software that the customer can't use; likely has no value, other than to your competitor.

Mike Caspar
CSP, CSM, OA2

References:

SCRUM - http://www.scrumalliance.org

     


Saturday, March 17, 2012

Continuing on the path to a "Test Driven Mindset"

In September, 2011, I made a post called "How to Introduce a Test Driven Mindset".  You can read it HERE if you're interested.

I had introduced OpenAgile to a small software development company with team members in Toronto, Montreal and India.  They have been using an iterative approach to development with continued improvements to productivity since then.  At the time, we talked about the concept of thinking in terms of "How are we going to test this" before writing code.

Many people (including developers) have a hard time seeing the benefits of thinking about testing as a way to save time in the development process.  Often, tests are created "after the fact".  Unfortunately, this is often what causes the biggest hurdle to learning the practice.  Trying to write tests for code that was not intended to be tested can be more troublesome than simply learning to create the test first.  There are ways to test legacy code.  I won't get into that here (at the end of this article, I'll put a link to wikepedia about mock objects or "mocking".

Back to the company that inspired this article...

It has been a tremendous help to the company to work on the highest ROI items first and to be moving forward toward their goal of potentially shippable software each cycle (OpenAgile uses cycles for iterations and encourages progress to be made primarily through Learning).

I have been visiting them for a few hours every week for a few months now, and have been reviewing problems they have been having with their application as they crop up.  They modify something and a problem re-occurs from code they fixed weeks ago, or even months ago.

As each cycle goes by, they have a larger and larger list of regression testing to do as the tests are not automated.  They find defects that they have fixed before because of a recent change.  Sound familiar ?

As I introduced the Mindset to them back in September, they knew exactly what I mean with my usual response; "Hey, you know EXACTLY how to improve this situation.  You just need to find a place to start."


I know it is very difficult for someone to immediately jump right on board the testing mindset. It can be a slow road and isn't easy to switch to if you're in fire-fighting mode... One step at a time is better than no progress at all.  

Often, the difficulty is that the idea of Testing is too abstract or not directly related to what the company does to have it make sense.  As defects from the past crop up, just gently bring them up as examples of problems that could be avoided with an Automated Test.

I find that nothing works better than real life examples.

Unfortunately, fixing old defects might be tougher to do as they were likely not designed to be tested.  Start with something easy.  You will find it likely that the team would prefer to start with something easy as well, so this will work out just fine.  You can even get the ball rolling by including the "FIRST" test into their testing environment or Source Control.  That test could simply be to make sure the testing environment works, such as 1+1 should equal to 2, or my favourite, Assert.AreEqual(true, true);

PLEASE be careful and prepared.  If things happen like they did for me at this company, one day they will take you up on your offer and want you to assist them to create a Unit Test.  You should be prepared to help them or, at least know someone who can.

It's a big deal that they are finally willing to give it a try.  Don't lose this wonderful opportunity to help the company out!

by Mike Caspar

......................

References:


Original Post -Sep 2011Introducing a Test Driven Mindset
OpenAgile http://www.openagile.com
Test Driven Development http://en.wikipedia.org/wiki/Test-driven_development
JUNIT (Java) http://www.junit.org
NUNIT (.NET) http://www.nunit.org


     

Tuesday, February 28, 2012

Explaining "Why" is important.

Direction ?


As your Agile adoption grows within the organization, you are going to have to let people know the "why" of the changes that are taking place.

....Read more of my post at agileadvice.com...