Thursday, December 19, 2013

Distributed Agile - Ten Principles



One of my goals this year was to define a set of principles for geographically distributed Agile teams. To accomplish this goal, I consolidated the lessons learned from several projects, interacted with project teams and collaborated with industry experts. That approached helped!  I have described these principles in my article titled ’10 Principles for Success in Distributed Agile Delivery’ published in Cutter IT Journal (Vol.26, No.11, Nov 2013).

The term ‘Distributed Agile’ continues to trigger critical questions, thought provoking discussions, and exciting debates. Such discussions and debates may appear to cause a restraining force against adoption;  but that is not true!  I am saying this because an increasing number of enterprises have started adopting Agile methods in geographically distributed teams. To know more, read this article.

Free PDF Article (limited time offer)  -  Download this article by visiting http://www.cutter.com/offers/rbavani.html and completing the registration form.

Happy Reading!

Friday, December 13, 2013

How Do You Manage Dependencies in Agile Projects?


I am writing this post to share my thoughts on dependency management and write about how it impacts Agile teams. The motivation to do this is my previous post 'Yet another Dreadful Dependency'.  We hear stories similar to this in our work life. Don't we?

A task we perform can be independent or dependent (on something else – say another task). It is independent when we are free to start and end the task without having to worry about anything else. It is dependent when we have to think and do it in a logical sequence by considering all dependent tasks.

Sometimes you need to wait for another task to finish so that you can start a new task. Sometimes you wait for another task to finish so that you can finish your current task. There can be a situation when you wait for a task to start so that you can finish your current task. Also there can be a situation when you wait for another tasks to start so that you can start a new task. That’s how we have 4 types of task dependencies FS, FF, SF, and SS. This is not a traditional project management stuff. This applies to all projects including Agile projects. When you think in terms of these 4 types of dependencies, you can streamline every iteration or Sprint by minimizing dependency issues.

I think, we need to think deeper than this. Can we categorize task dependencies in some other way? Do we have techniques to deal with such dependencies? Let me explain.

How do we categorize dependencies? We can group dependencies under several categories such as

Technology Dependency – This category is about dependencies arising from architecture, design, coding, components etc. Here are some examples.
  1. Program A cannot function until Program B is developed
  2. We have to change the program as component X has changed
  3. We cannot develop layer-Y in our architecture until layer-Z is ready
Data Dependency ¬ This is about dependencies related to data readiness to complete project tasks. These dependencies are often ignored in projects as project teams find ways to create data in some way or the other. I am sure we learned ‘logical dependency’ and ‘physical dependency’ in our DBMS course. I am not talking about those here. Here are some examples.
  1. Acceptance Tests cannot start until we get adequate data for testing
  2. Data sources A, B and C need to be in sync to start integration testing
  3. Defect X cannot be reproduced until the logger is turned on to capture the trace of events
Application/Service Dependency – In this category we come across dependencies involved in developing, maintaining or testing your current application with reference to other related or dependent modules, applications or services.

Build Dependency - I have not included build dependency under technology dependency because dependencies related to build management deserve a separate mention. When we create builds we identify dependencies and compile programs in the right order. Also, when it comes to several interrelated applications or a suite of applications, build dependency becomes a pivotal point. There are several techniques and tools to identify and manage build dependencies.

Operational Dependency – These category includes other operational dependencies such as release dependencies, data migration dependencies, connectivity dependencies and so on.

These sound more conceptual and theoretical. Can we look at dependencies in a different way, analyze and understand them?

Is there a simpler way? Good question. Fair enough! With all these categories of dependencies, our discussion can become overwhelming. I know. We need to have a simpler way of identifying and categorizing dependencies. A logical way is to identify dependencies at three levels – product roadmap planning, release planning and iteration or Sprint planning. However, awareness on different categories of dependencies is necessary. With that awareness we won’t miss out any.

For each dependency, all we need to do is ask these questions.
  1. Is this an internal dependency (local to the project) or external dependency?
  2. When will it hit us - short, medium or long term? How much time do we have to plan and manage it?
  3. Is this dependency going to last for a week or couple of weeks or months or more? Or is it perpetual or recurring?
These questions help us understand the circle of influence (internal or external), estimated time of start, and expected life or duration. Without these we cannot understand the gravity or impact of dependencies. Without these, we will not be able to reduce anxiety and spend our efforts on the most important tasks. With out these we will not be able to identify the right techniques to handle dependencies.

What are the techniques?  There are many techniques. Here are some pointers to those techniques.
  1. Learn and apply design by contract and practice DIP (Dependency Inversion Principle). A downloadable PDF on design principles is available at http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf.  It includes information on DIP. If you are a hardcore programmer, read this post for more information http://www.pelshoff.com/2012/02/dependency-management
  2. Use stubs, mocks etcetera to manage the situation until you get the real objects to depend on.
  3. Don’t ignore data dependencies. If something is necessary – for example, production data, you cannot live without it. Make it a criteria. Don’t accept junk data for testing.
  4. Application/Service dependencies can be haunting. What if a service breaks in real time? A way to handle this is to build robust exception handling mechanism. In addition to this, check dependency issues through automated scripts or snoop error logs. Here is a PDF file on managing dynamic service dependencies - http://proceedings.utwente.nl/13/1/S5-1.pdf.
  5. When you work with multiple teams (for example, Scrum of Scrums or with multiple dependent projects) dependency management has to be handed through proactive thinking, asking questions and triggering discussions in meetings. In addition to asking ‘Are we dependent on other teams?’ it is necessary to think ‘Is there a team that depends on us?’ 
If you are a researcher or student here is a PDF white paper from OOPSLA 2005 - http://www.lattix.com/files/dl/wp/oopsla05.pdf.

I think I have shared a good number of concepts and practices here.  How do you manage dependencies? Do you use any tools or techniques? Let us discuss.

Wednesday, December 4, 2013

Yet another Dreadful Dependency!


I introduced Joe to you in Oct 2013 through our conversation on his question ‘Velocity Dip or Double Dip – What to do?’ Subsequently I wrote a post on how he affirmed ‘Readiness at the Starting Point Matters!’ to his product owner. Last month we met again to discuss about ‘Building on Legacy Code’.  I trust you read all these posts. I am writing this post to share another story. This story is about dependencies in software projects.

Last week I was in a 1-day workshop on emerging technologies. To my surprise, I met Jim and his technical architect, Alan in that workshop. We had some interesting conversation over lunch.

During the first five minutes of our conversation Alan was little skeptical on how iterative and incremental development works in large projects. That is how I perceived him because of his crisp answers and body language. He was not ready to open up and talk about issues on the ground. I wanted to understand his views. I had no other option but asking him pointed questions. And I started.

“Alan, tell me. How is it going in your projects? I know you have multiple projects – big and small. What is one single big issue that bothers you?”

Alan smiled and responded. “Well there are multiple issues. There are issues because of dependencies. How do we handle them? I am working with a large team – there are multiple teams. These teams are spread across three locations. Last week, we were about to complete a feature. That is when one of our team members alerted about a dependency. Our code depends on what other teams are developing. This is not the first time. In spite of multiple reminders, the other team did not act on time and complete their work. We are just a month away from our release! Believe me, it is yet another dreadful dependency! ”

“Let me add some more information.” Jim chimed in. “This is a large project. Initially we thought that our teams spread across these three locations could function smoothly. Because we put them on three separate modules. I can say, fairly independent modules. Now, we are deep inside the project. We understand that on implementation point-of-view – I mean, in terms of design and coding, there are several dependencies. Those are hurting us now!”

Looking at Alan, I probed, “That is, you are not able to finish something because something else is not finished by another team?”

He nodded and said, “Yes. Sort of. You can say that.”

I wanted to know more about what happened in their project. I continued. “Joe, I think we are good at managing ‘Finish to Start or FS’ dependencies. For example let us assume that we plan a trip from point A to point C with one hop in point B. Let us say want to go by air. The entire trip is covered in two flights - one from point A to B and the other from B to C, we know that there is a dependency there. I mean unless you reach point B on or before X hours, you cannot start from point B at Y hours. That’s is obvious. We plan for sufficient hours between the arrival of the first flight and departure of the second. We do this in our projects too. Simple. Isn’t it?”

Joe smiled with his short response. “Yes. We do. But I am not sure if we identify all dependencies and explore all possibilities. Could it be the drawback of iterative and incremental development? I don’t know.”

Alan, with his curious expression “I partly agree with Joe. I have a question. Finish to Start is interesting. What are the other types? Is there a Finish to Finish? How about a Start to Finish and a Start to Start? Do we have all these types? FS, FF, SF, SS?”

“Well, Yes. That is correct. I think the dependency issue you told me about in your project is a Finish to Finish dependency. That means that unless that other team finishes some work, you cannot finish your work.”

“Right! Absolutely!”

“So, what do we do about these?”

“Plan, execute, and monitor progress. These three are important for all types of dependencies. I mean plan, execute and monitor. Obviously! We know that. In spite of these if you come across issues, you will have to manage those issues! What do we do when our first flight from A to B is delayed? If we carry a refundable ticket and if there is ticket available in a flight on the same day, we reach after few hours of delay. If we carry a non-refundable ticket, and the flight operators are different then the solution is costlier - we get some refund but we need to find out way home by buying another ticket or doing something else to travel. That will be an expensive ticket! So, what is the take away here? We need to plan. We need to build some safety net or a backup plan in some cases. That is because dependency is a risk. If a dependency is perceived as a big risk, you plan to mitigate it. In our example, the mitigation plan is your refundable ticket with enough overlay. In spite of this mitigation plan if that dependency becomes an issue – for example, due to bad weather or flight delays you miss your second flight, you have to manage that issue. That will impact your journey. You may not reach on time!”

“Interesting example! So, do you say that we must plan for all dependencies?”

“Well, I think we must be aware of all dependencies and their impact. The next step is to plan. Without awareness we cannot plan. Without planning we cannot put in measures to reduce the impact of dependencies.”

“Of course! I agree. Is this all part of Scrum or XP or something else?”

“I don’t think so. And you know this better than me! These is a project management practice. You must be able to pick and choose practices like these and include them in your methodology. Then it becomes your hybrid methodology. Methodology is project specific. If that is what matters, that is going to work for you!”

“Well, I think it is clear now! Thanks a lot!” said Alan.

“Sure. We need to go now. Our next session will start in five minutes. I will share some more thoughts on project dependencies next time.”

With a smile, Alan acknowledged, “Thank you. And yes, we talked about these theoretical concepts. It is worth exploring some hands-on techniques as well. May be next time.”

“Of course. I will share those in my next blog post as I am on a long leave and may not be able to meet you until Jan 2014. Or we will discuss about those techniques and all that when we meet.”

With that parting note we started walking towards the conference room looking forward to an interesting post-lunch session.

Dear Readers, I am sure this post is a long but a fast read. How do you manage dependencies? Did this post trigger any thoughts in your mind? Feel free to share!

Monday, December 2, 2013

Distributed Agile: Questions and Answers



Tom Cagley (http://tcagley.wordpress.com/) interviewed me on distributed agile. This interview happened sometime in July 2013. We spoke on phone - Tom was in US (East Coast) and I was in India (Pune).

Tom asked me several interesting questions and engaged me in a great conversation. Here are some samples.

1) What do we mean when we say "distributed agile"? How do words like off-shoring, outsourcing affect your definition?

2) Why do organizations seem to have a difficult time with agile with multiple organizations and locations?

3) What are the principles that you think should guide the adoption of distributed Agile?

4) Recently you have been blogging about Agile in stage-gated environments. How is Agile possible in that environment?

5) Recently you spearheaded the creation of the Global Distributed Agile Consortium. Please tell the SPaMCAST listeners about the project and where you see it heading?

My answers to all his questions are available in Tom’s podcast at http://spamcast.libsyn.com/s-pa-mcast-266-raja-bavani-distributed-agile-revisited.

Tom runs 'Software Process and Measurement' (SPaM) casts regularly. The Software Process and Measurement Cast provides a forum to explore the varied world of software process improvement and measurement. The SPaMCast covers topics that deal with the challenges on how work is done in information technology organizations as they grow and evolve. In a nutshell, the cast provides advice for and from practitioners, methodologists, pundits and consultants!

Go visit his site and listen his podcasts and read his blog post at regular intervals! It is worth an experience! Many impressive interviews by industry leaders in Software Engineering are waiting there for you!

Sunday, November 17, 2013

Building on Legacy Code


Joe came by last Friday to meet me. He called me the day before and mentioned that he wanted to discuss about an escalation from his customer. Escalation from customer is a serious concern. All of us know.  I tried to connect it with my previous meeting with Joe. I had no hint on what could have happened to cause this escalation.

We decided to meet at a nearby restaurant on our way to work.  By the time I arrived, Joe was waiting there for me. We wanted to make this a short meeting not exceeding 30 minute.

We started our conversation and placed our orders. Joe started it slowly after a quick icebreaker on some of the trending news items.

“This is about the recent Sprint. Even after passing all acceptance tests, we came across a defect in the system. It blew up the whole thing. The VP of engineering, our customer is furious. ”

“Joe. Could you please be more elaborate and tell me what happened?”

“Well, we delivered the right thing. It is the legacy code that had hidden a bug. This legacy code was developed years ago. May be five years or seven years ago by some developers at customer site. We are held responsible for something that fails in the legacy code.”

“Why so? Do you think the acceptance test could have been improved to cover such scenarios?”

“I don’t know. We wrote the acceptance tests. We considered the Definition of Done and the tech lead at our customer site reviewed all test cases and passed them. When we did our Sprint review, all of us agreed that the stories were done and delivered. But this bug came up at a later stage.”

“Tell me. Has this happened before? How can you solve this problem?”

“It has happened couple of times before but it was not a big concern. This time it became a red alert. This is not our problem. This is because of the legacy code. It is not modular. It is messy. Every time we write a piece of code we are worried because the code we write has to work with legacy code. Our customer does not understand this reality. What can we do now?”

This is when I decided to nudge him a bit.

“Joe, I understand what you are talking about. This problem is affecting you and your team. You need a solution this problem. Take ownership. Why not?

Joe understood the way I nudged him. He repeated what I said and continued. “Take Ownership! Why not? Could you please tell me what you mean by this? I can take ownership of a problem I caused. Why should I go and fix a messy code?”

I paused for a while and explained him the importance of taking ownership. He was listening to me. I continued.

“Joe. A similar escalation happened in my project years ago. I convened a meeting with my team. We analyzed the legacy code and listed out all issues. We shortlisted and wrote a 2-page document to list the top-10 issues. We added our recommendation on resolving those ten issues and listed the benefits. We presented this to our customer. We had to go through a tough negotiation. Finally, our customer gave us a go ahead. Our team got the necessary budget and schedule to resolve those ten issues.”

“Interesting. Does it help you make the legacy code clean and prevent all issues?”

“Yes. To some extent. It helped us in two ways. First, we cleaned up the source code by fixing the top ten issues. Those were broad issues related to design and coding standards. Second, we understood the legacy code very well by improving the code base. This helped us prevent several issues. How about considering a similar approach in your project? How will that work? Isn’t it an opportunity for you? Take ownership!”

“Yes. It is! I can’t think about a better idea. I must do something like this.”

“Joe, that’s good. Take this as an opportunity to turnaround and win customer confidence. I am sure you will.”

“Sure I will. Thanks for your time! It is time to go to work! I will catch up with you later!”

“Good luck Joe! Keep me posted!”

Our short meeting over breakfast came to an end. Later that day I couldn’t stop thinking about numerous incidents related to taking ownership. It happens at work! Isn’t it?

Thursday, October 24, 2013

Readiness at the Starting Point Matters!


Joe started it right. He was trained and certified. He had played the role of project manager in several projects. He was ready at the starting point. And he started on his first agile project. Was that enough? May be not. Because this was his first agile project.  He was a rookie Scrum Master. But, that is how many of us start and gain some experience. Don’t we?

Couple of weeks ago, Joe’s team velocity had a dip or a double dip. Joe was curious to seek some help, ask questions and get some suggestions.  Our first meeting helped him do some of these. After our first meeting, I was involved in an external event followed by a customer visit. Joe stayed in touch with me over emails and came down to meet me last Friday. He was relaxed and confident.

The child in me started the conversation with a smile.  “Hi Joe! You are early today and you are fast. Looks like the velocity has increased!”

With a smile he responded.   

“Well, I am early. I want to fail early and fail fast!  I have something very interesting to tell you. I had a one-on-one conversation with my Product Owner. He understands.”

“Understands? What does your PO understand?”

“He understands that readiness at the starting point matters! Let me explain.”

I liked the way he put it across to me. He explained in detail about his conversation with his Product Owner. I stayed focused and listened as he narrated the whole thing.

Joe prepared for this conversation– he did enough home work. He grasped the current state of fuzziness in user stories. According to him more than 60% of user stories underwent major changes. The figures and facts presented by Joe helped his Product Owner understand the gravity of the situation. That is when they agreed that the definition of ready (DoR) is as important as the definition of done (DoD). In short, ‘Readiness at the starting point matters!

Another fantastic thing he did was to help the Product Owner understand that ‘Velocity’ is not the one and only metric to care about or worry about.

As he explained all these to me I sensed a great deal of common understanding and rapport emerging between the budding Scrum Master and Product Owner. And I was just nodding with a smile. He continued.

“Now the good news is that we are going to start another project soon.”

“Yes. That is a good news! Is there a follow-up news?”

“Well. Yes there is. But that is not a good news! My Product Owner says that the new project involves development of a complex application and the requirements are evolving. He is not sure if we can ensure readiness at the starting point. He is firm. He is not going to provide us groomed or ready user stories.”

“Does it mean that the definition of ready and definition of done will evolve day by day during iterations?”

“Yes. I think so. That is the bad news! He wants us to deliver.”

“When is this new project starting?”

“I forgot to tell you that. It is going to take a month or two. I want to discuss this with you in our next meeting.”

“Sure. Why not?”

With a sign of mutual agreement on what to discuss next time, we ended our 30-minute meeting.  Joe, with a confident look, waved at me and started walking towards his car. I am sure he will have some interesting things to discuss in our next meeting.

I am sure Joe will be in a better shape with the experience he has been getting in his first agile project. In future, he will be able to scale up and handle larger teams too.

Readiness at the starting point matters. However, can we afford to keep waiting at the starting point to get ourselves ready? Or should we move forward as we become ready? The answers to these questions depend on one thing – the definition of ready. Once we agree on this definition, we must work together without conflicting each other on whether something is ready to start or not! Obviously the definition of ready is going to be context-specific.

What do you think?

Friday, October 11, 2013

Velocity Dip or Double Dip – What to do?


Joe is a new to agile software development.  A year ago, he attended training programs on agile methods and learned more through his sporadic reading on topics related to Extreme Programming, Scrum, etc. He did not get an opportunity to practice though - he continued to play the role of project manager in other non-agile projects.

As you know, 70% of learning happens through practice, hands-on experience or problem solving.  About two months ago he got that opportunity he was looking forward to - his first agile project started.  A month before the start of this project he completed a certification program which provided him additional awareness and may be some confidence on how to lead agile projects and work with agile teams.

His project follows practices from Scrum, XP and other methodologies. He is a rookie Scrum Master.  This is the first time he and his team members are putting several agile practices into practice. They are experimenting and exploring. They are trying to make sense out of their experience iteration after iteration.

Last week weeks ago, Joe met me.   He wanted to discuss about the teething issues in his project. He needed my suggestions or thoughts on such issues.

We met on time and spent the first five minutes in catching up with some general topics.  Then he started on one of the issues in his project.

“Velocity is pretty much the same as throughput.  Is that correct?”

“Yes. You can say that. In simple terms it is the units of work delivered per iteration. What has been your team’s velocity? How is it trending?”

“Not good.  We are not seeing any increasing trend. It is pretty much the way the global economy is. Initially it was a single dip. Now we see a double dip!”

He smiled and I did too as I continued with my questions.

“So, tell me about your team. How is your team moving forward? Are they …”

“Well, the product owner is anxious.  Well, he is upset.  Yesterday we had our iteration planning session.”

“Concerned about the double dip?”

“Yes. Every dip is a matter of concern! How do we handle this situation? What do you suggest?”

“How was the team retrospective? What has the team reflected on?  Do you believe you can sustain?”

“I think so.  Our product owner knows the root cause.  User stories are not stable.  We have to do a lot of back and forth in refining most of them. That is tough.  This impacts our productive hours during the iteration. In spite of this he expects us to maintain an upward trend in velocity. He asks pointed questions on our velocity trend. Tell me. Is it this double-dip bad? What should we do?”

This is when I took a pause and then assured him firmly that it is ok to have a double-dip.  Why not?   A dip in the chart is okey as long as you collaborate enough, be transparent, identify root causes, implement corrective actions, resolve issues and move forward in the right direction.   ‘Fail-fast-fail-early’ is something we need to encourage and feel happy about.

Next, I asked him, “What are the success parameters in your project? How do you measure success? Is Velocity the only parameter or do you collectively look at other metrics?”

He understood where I was getting into. With a nod, he responded.

“I understand what you are talking about. I think we have not established a common understanding on our success parameters. We do not have a sound governance mechanism in place. I have a fair understanding on what to do now. I am going to take this up and discuss with our product owner.”

With a smile, I ascertained his approach. I think he wants to solve problems,  improve and reach the destination.

Before we parted, I shared with him my thoughts on the signs of collaborative spirit and my experience on how to build rapport with a remote product owner.

Joe is confident. He is going to meet me again.  I will come back to you on that meeting soon.  He met me after couple of weeks to discuss about an interesting thing  -  read the next post to know what happened in our meeting

Related Posts:





Friday, October 4, 2013

How Can We Make Software Engineering Curriculum Interesting?


'How Can We Make Software Engineering Curriculum Interesting?' This was the topic of our panel discussion in the workshop on software engineering education and training (WSEET) -  a pre-ICSE 2014 event. The objective of this discussion was to explore different ways to  make ‘Software Engineering’ course interesting.

Think about the class room sessions on Requirement Analysis,  Estimation Techniques, Project Planning, Methodologies, and so on!   Are these sessions too theoretical?  Why aren't these sessions interesting? What do we need to improve and make it interesting?

Here are some ideas and suggestions that emerged out of our discussion.
  1. Class room interactions on software engineering supplemented with hands-on projects to small groups of students is a way to combine theory with practice.
  2. Learning from open source projects is an opportunity that never existed a decade ago for students.  Downloading open source code, studying the code, adding new features or enhancements will make it an interesting learning experience.
  3. Making class room sessions interactive instead of presentation driven monotonous lectures is a must.
  4. In order to get an understanding of what happens in the industry it is good to consider invited lectures (by industry experts), and  learning from recorded video sessions of international experts.
  5. Case study based learning (similar to the Harvard Business School model) is very appropriate in software engineering courses. Students can learn from both successful and failed project case studies.
There were several other related suggestions.  According to the 70-20-10 formula,  70% of what we learn comes through practice and it makes lot of sense to supplement class room sessions with projects, hands-on practice and several other techniques (such as case study based learning or invited lectures).

These days it is very easy to ensure that software engineering curriculum of a university is second to none in the world. We have access to the curriculum of top universities. We know the top reference books and students have access to lots of high-quality material on the web. Eventually, making the curriculum ‘interesting’ is a delivery issue.  There are 3 groups of key players or stakeholders who have to play their role to make it interesting.  Here are these groups.

Administrators or senior management of educational institutions:  Their role is to provide the infrastructure with adequate computing facilities and support partnerships with industry and provision incubation centers.  In order to do this it is necessary to revisit the mission, vision and goals of the institute from time to time.

Faculty members:  Inspiring teachers pull students.  If we want our course to be interesting, we need to carry an interesting personality and attitude.  We cannot afford to settle down with the same old reference books and examples.  We must be lifelong learners so that we do not stagnate. Because, when we stagnate we become dull and uninteresting.

Students:  Students have to be curious, interactive and inquisitive.  Students must be willing to read, interact, and collaborate.  They must be ready to solve challenging problems and stay away from the temptation of doing just enough to score grades.

With these measures, I am sure learning software engineering can be very interesting. 

What do you think?  Do you have any ideas or suggestions?

Tuesday, September 24, 2013

How Do We Learn? - Aren't You Curious?

Image Source: http://gifrific.com

This blog post is a recap of my session at Agile Goa 2013. I am writing this to benefit the attendees as well as all readers.

Look at these kittens.  Aren’t they curious? What is this apparatus these kittens are playing with? Aren't you curious? It is Newton’s Cradle.

What is Newton’s Cradle? It is an apparatus used to explain the law of conservation of momentum and energy. More info on this at http://en.wikipedia.org/wiki/Newton's_cradle.

We need to be curious. In order to learn effectively and efficiently, we need to be curious about how we learn. Some of us may feel that learning is a done deal. We are out of our college or university education. We are employed. And we settled down with a feeling that learning is not compulsory. Do you think so?

“Learning is not compulsory, neither is survival.” - W. Edwards Deming

How true! With an open mind and continuous learning attitude, you stay young, current and relevant!

“Anyone who stops learning is old, whether at twenty or eighty.” - Henry Ford

And to become a master in your field you need to know a secret.

“The secret to mastery in any field is to forever be a student.” – Martin Palmer

Learning is not limited to children.

“Learning is what most adults will do for a living in the 21st century.” - Alfred Edward Perlman

How can we enable learning? How can we enable learning by creating curiosity?

“You can teach a student a lesson for a day; but if you can teach him to learn by creating curiosity, he will continue the learning process as long as he lives.” - Clay P. Bedford

Agile methods emphasizes on team learning. Do you want to know how and why?

Read   Why Agile Teams Need to Know How to Inspect and Adapt?

Inspect and Adapt can be applied everywhere if you and your teams are ready to implement. To know more on this read Inspect and Adapt: Simply a Great Agile Deal?

We express our curiosity in terms of questions. Are you afraid of asking questions?

“He who is afraid to ask is ashamed of learning.” – Danish Proverb

“The illiterate of the 21st century will not be those who cannot read and write, but those who cannot learn, unlearn, and relearn.” - Alvin Toffler

Also Read (to know about 'Learning Styles' and more):

How Do We Learn – Part 1

How Do We Learn – Part 2

Saturday, September 14, 2013

Inspect and Adapt: Simply a Great ‘Agile’ Deal?


Agile teams practice team retrospectives at the end of iterations. Retrospective is a practice prescribed by Scrum – one of the popular agile methods.  Similar practices exist in other agile and iterative methods too.  Retrospective is a team-personal iteration-end activity. It happens in a meeting room or a venue where all team members meet and spend quality time in reflecting on what went well and what did not go well. Everyone in the team gets to talk and express their take.  This is for the project team only - there is no middle or senior managers who are from either a PMO organization or other external entities.  In other words, retrospectives are not attended by someone external to the team and up in the hierarchy. The only exclusion is an agile coach who helps the team on need basis.  When team members reflect they get to inspect and adapt. This results in continuous improvement because of collective decision making at a team level.

There are two questions.  First, ‘Why do agile teams need to know how to inspect and adapt?’ The answer is simple but profound. I am sure you clicked that link and read the article. Understanding the significance of ‘inspect and adapt’ and doing retrospectives right puts agile teams in to virtuous cycle.

Can you guess the second question?  I said that Waterfall teams introspect only at the end of the SDLC.  You may disagree and say, “Learning, inspecting and adapting are equally important to all project teams irrespective of traditional or evolutionary methodologies.   Learning is a lifelong process.”  And ask, “Is ‘Inspect and Adapt’ simply a great 'Agile' deal?”   That is the second question!

The answer is ‘Yes’.   This is because long ago when we followed traditional methods, there were no retrospectives or similar team-personal practices to enable the team members inspect and adapt.  Even if we were aware of the underlying concept of retrospectives, we did not practice it systematically.  In most cases, an intention to ‘Inspect and Adapt’ was triggered in PMO meetings or other similar events. We got instructions or directions from those who were up in the hierarchy about how to adapt or what else to do to make things better. Sometimes those instructions were not right because they were not plugged into day-to-day happenings in the project.  Otherwise, we the team members did not nurture those instructions as those instructions where not our babies!  There was no collective decision meeting.  All team members were not involved!  To sum it all, we did not spend those dedicated 60 minutes.

Let me extend my answer from a short ‘Yes’.  Here it goes.  Big deal!  This is common sense. Any team - not just software project teams and teams following any methodology – not just agile methods can inspect and adapt.  That makes lot of sense! Isn’t it?  Having said that let me emphasize one thing.   We need to articulate this practice, nurture it and enable teams understand and reap the benefits. Else, it will remain a good thought. The reason is obvious.  Practicing ‘Inspect and Adapt’ is indeed a big deal!

What do you think? Let us discuss.


Last year I wrote 'The Power of Inquiry: Coaching Tips for You!'.  Powerful questions help in coaching as well as team learning. This will lead to effective retrospectives and enable your team inspect and adapt.

Monday, August 19, 2013

Do You Cycle or Swim?



Looking at this title, you may wonder what this post is about.   This post is about one of the challenges we face in geographically distributed teams.  This is about communication among distributed team members.  In distributed agile teams this surfaces at early stages because of the fundamental characteristics of agile projects - short delivery cycles, the need to communicate regularly, etc.

Communication and coordination are among the most challenging areas when working with geographically distributed teams spread across different time zones, countries and cultures. English is spoken in several countries. However spoken English in every region has its flavor  - I mean, the usage and accent are differ from country to country.  Do you find it difficult to communicate and coordinate with geographically distributed teams or customers? Do you find it hard to decipher their accent or pronunciation? Are your team members going through this issue?  If yes, you will like my article 'Do You Cycle or Swim' published in Agile Record.

Download a free PDF copy of this article!

Tuesday, August 6, 2013

My Session at Scrum Gathering India 2013 - Part 2



This is the second part of my post about my session titled, ‘How Do We Learn? -  A Key Question for Practicing Scrum Teams’ delivered at Scrum Gathering India 2013.  In the first part I started with the 70-20-10 formula and ended with learning styles.  We are individuals and our learning styles vary.  We are team players too.


We are team players
It is most likely that Scrum team members are team players. This is one of the key factors that make teams successful. When we work in teams, we learn a lot.  We learn by pairing, helping, discussing, playing, following, and so on.   Team retrospectives help us in learning.

Active learning happens significantly in group setting or in teams.  Our retention rate increases when we participate in demonstrations, group discussions, hands-on practice or learning by doing, and teaching as shown here.


When I was putting this in front of a group elsewhere, someone asked me, “Do you mean to say that we can live without class room sessions?”

The answer is  'No'.  When you have an instructor or facilitator or a teacher who is effective, your class room sessions are going to motivate you and keep the flame burning throughout your life!  This is the significance of class room sessions.  Also, class room sessions are appropriate for some topics. To reiterate, we are not undermining the power of passive learning. We are here to understand the effect of active learning as well.  How many of us contribute to active learning in our teams?

According to Bloom's taxonomy, when we limit ourselves to remembering, understanding, and applying, we operate with lower order thinking skills.  When we move up by analyzing, evaluating and creating, we acquire higher order thinking skills.



Now the questions I have are, ‘Should we keep practicing and delivering or go beyond that?  Should we limit ourselves to lower order thinking skills? And don't we have to acquire higher order thinking skills?’

Where do we start?
We start by believing what we do.  We have to regularize what we do and make it a habit.  We have to meditate enough to rest ourselves.   We have to become curious.  Moreover, we must align ourselves to maximize the outcome of learning.

What do we do when we do not have curious team members?  This is a question that came across in my session.   The ultimate answer is, “Make them curious.”  How?  This is where team interaction helps.   You have a key role to play here! You become curious. Identify one or two team members who are ready to spread this 'curiosity' virus.  Check if you are involving your team members.  Identify and involve a coach.   Eventually, your team members will start showing curiosity.  And you will start nurturing a learning team.

Takeaways
Here is my list of takeaways. I am sure you have some more. Please feel free to let me know through your comments.
  1. Class room sessions are necessary (in some cases) but not sufficient. 
  2. Reading is essential.   Thinking, validating and experimenting are going to help you improve.
  3. Practice a lot. Hands-on experience maximizes learning.
  4. Is that it?  No!  Involve your team members.
  5. Share.  Teach. Become a mentor. Help your team members.  These will benefit you as well as your team.
  6. Start moving up from lower order thinking skills towards higher order thinking skills.

Watch these again
Here are the two video clips we watched together at the end of my session.  These are worth watching again.
  1. Bring On the Revolution by Sir Ken Robinson
  2. Three Rules to Spark Learning by Ramsey Musallam



My Session at Scrum Gathering India 2013 - Part 1

I believe that writing a blog post to communicate with you is more effective than sharing a slide deck.   That works for me and you because of two reasons.  First, my slide decks are very crisp and heavy with pictures and animation.  I use them as presentation tools.  They are not for offline communication.  Second, blogging helps me articulate my thoughts and present them in a conversational style, add some stories and summarize the takeaways.   When this happens to be a 2 to 5-minute read, it saves time as well.   This blog post is about my session titled, ‘How Do We Learn? -  A Key Question for Practicing Scrum Teams’.

How do we learn? This is one of the seemingly most simple but important question you and your team members need to ask yourself and think through.  We are professionals.  Obviously we know why we learn and what to learn.  However, many of us seldom think enough about how we learn.



We are individuals
We are individuals. We attend class room sessions at colleges or universities. We go to conferences. We attend workshops and seminars.  We seek mentors or coaches. Mentoring and coaching are essential aspects of professional life these days.

Does it mean that we can put as many adults through class room programs and start churning?  No!  Let us stop churning!

Image Source: http://mimiandeunice.com

Let me tell you a story. It happened last year.  That day I completed a group session to spread awareness on Agile Software Development. It was a group of thirty young engineers.   They were part of agile teams.  They attended my session to know more and wanted me to clarify their doubts.  At the end of my session, I looked at one of them and asked, “Now tell me, what the next steps are for you and your team?”   He waited for a second and replied, “I think we will attend more detailed training programs on continuous integration, unit testing, etc.”   I paused for a moment before I encouraged him to start hands-on learning, or learning by doing things.   He was not aware of the 70-20-10 formula.

70-20-10 formula
According to the 70/20/10 formula, which is a concept developed by Morgan McCall, Robert W. Eichinger, and Michael M. Lombardo at the Center for Creative Leadership, 70% of learning happens through practice, hands-on experience or problem solving, 20% of learning happens when we work with experts or coaches, observe them and listen to their feedback, and 10% of learning comes from formal training.

We read books. We browse the internet.  We validate what we hear or read by going through additional references. Sometimes we learn by writing.

We learn by practicing, experimenting, exploring, observing, applying and thinking.   What we learn from class rooms and conferences or workshops is just the beginning. Are we doing enough practice?

We learn from our mistakes. We say ‘fail fast, fail early’.  It does not mean that we can fail frequently and learn from mistakes because doing so is expensive.   Sometimes, mistakes motivate us to unlearn. And we can’t stop learning from mistakes.   And we cannot avoid learning from others’ mistakes!

Image Source: http://mimiandeunice.com
Involve me
Have we ever seen team members who feel that they are not being involved? As a Scrum Master or a leader do you involve all your team members?  Involvement is essential to kindle learning.

“Tell me I forget. Show me I remember. Involve me, I understand.”  -  Chinese Proverb.
  
Teaching is an effective way of learning. How about making teaching or knowledge sharing a culture in your team?   When there is no involvement, team members do not come forward, they do not share their ideas, and they do not volunteer to teach and their participation remains sub-optimal in retrospectives.

Learning Styles
Then there are learning styles.  Here are some examples.

Visual – If this is your style, you prefer using pictures, images, and spatial understanding.
Auditory/Musical - If this is your style, you prefer sound and music for learning.
Physical/Kinesthetic – If this is your style, you prefer the sense of touch.
Solitary – If this is your style, you prefer to learn alone through self-study.
Social - If this is your style, you prefer to learn in groups.

Even though we work in teams, we need to keep in mind that the learning styles of our team members are not going to be the same.   Some are going to be great experimenters and the others are going to be great contributors to discussions.   We cannot force one way or one style of learning on all team members.

So what do we do? Find more on this in the next part.

Monday, July 29, 2013

Tutorial on Effective Dashboards: Takeaways and References


This blog post is about my tutorial ‘How to Build an Effective Dashboard for CXOs, Senior Management, and Business Leaders’ at the Annual Conference of Software Process Improvement Network, Bangalore Chapter (BSPIN Annual Conference 2013) on 26th July.   It was a memorable experience delivering this tutorial to more than seventy five or eighty attendees clustered around twelve round tables in a big conference room.  Considering the number of participants, I think we had very good exchange of ideas, questions and discussions.  And we spent the last 15 minutes in group discussions summarizing the takeaways. That was a fulfilling experience. Wasn't it?

Many of you wanted to know additional examples on visual representation. In this blog post I have summarized the takeaways and shared a list of references. These references include several examples on visualization techniques and good practices.  Enjoy!

Takeaways
  1. Dashboard is a communication tool – not an analysis tool.
  2. Make it customer or consumer specific.  A dashboard that suits one category of audience need not suit another category.
  3. Dashboard design and delivery does not happen in one shot.   Customer or consumer feedback is very important for dashboard improvement.  Without this dashboards will become stale.
  4. Identifying the right data (metrics and measures) is important. Goal-Question-Measure (GQM) technique helps in identifying the right data.   Metrics are context-specific, multidimensional, and seasonal.
  5. Ask questions. For example, ‘What are the top n questions (say 3 questions) do you want your dashboard to answer?’ can help you in doing the right thing.
  6. Removing the unwanted is equally important.  Ask, ‘What can be removed from this dashboard?’ in addition to asking, ‘What is missing in this dashboard?’.
  7. Consider a good balance of enablers and drivers.   Check if you have the right set of leading and lagging indicators. 
  8. Use the right representation. For example, why do we use Red-Amber-Green to represent project status? Why not follow something better – for example, weather reports?    
  9. Choose the right visual elements such as colors, charts etc.   When you use bar graphs make sure that they show data values in specific order (ascending or descending).  
  10. Data correctness, accessibility and usability are equally important.
  11. Understand and apply ‘Balanced Score Card’ principles when you design dashboards. Also, feel free to unbalance the score card when necessary.
  12. Make sure that your library has copies of the book Information Dashboard Design, The Effective Visual Communication of Data by Stephen Few (O’Reilly, 2006).

References
  1. Effectively Communicating Numbers by Stephen Few 
  2. Common Pitfalls in Dashboard Design by Stephen Few  
  3. Uses and Misuses of Colors by Stephen Few 
  4. Practical Rules for Using Color in Charts by Stephen Few
  5. Choosing Colors for Data Visualization by Stephen Few
  6. Pervasive Hurdles to Effective Dashboard Design by Stephen Few
  7. Telling Compelling Stories with Numbers by Stephen Few 
  8. Show Me the Numbers – Designing Tables and Graphs to Enlighten by Stephen Few 
  9. Information Dashboard Design by Stephen Few 
  10. Effective Dashboard Design by Andrea Janes, Alberto Sillitti, and Giancarlo Succi 
  11. Guide to Dashboard Design  - Juice Analytics 
  12. 10 CIO Dashboard Tips  - dashboard.com
  13. 5 Characteristics of a CIO dashboard  - dashboard.com
  14. 6 Innovative Dashboards worth Learning From  - Juice Analytics

Do you want to add more to these lists? Please share.

Friday, July 19, 2013

My Next Two Speaking Sessions


Next week, on Friday (26th July) I am speaking at BSPIN Annual Conference. The topic is 'How to Build Effective Dashboards'. I discussed some elements of this tutorial in my earlier posts.   BSPIN is the Bangalore chapter of Software Process Improvement Network.   BSPIN Annual Conference is a 2-day conference scheduled on 26th and 27th July 2013.


On Saturday (27th July) I am speaking at Scrum Gathering India Regional 2013, in Pune. This conference is scheduled on 26th and 27th July.  The topic of my session is 'How Do We Learn? - A Key Question for Practicing Scrum Teams'.

Team members of Scrum teams are busy delivering working software iteration after iteration. Do they get adequate time and opportunities to learn?  Are they too busy delivering working software? Do they find it hard to ensure work-life balance? Do they feel that they learned nothing much at the end of their project?

How do we learn? This is one of the seemingly most simple but important question you and your team members need to ask yourself and think through.  We are professionals.  Obviously we know why we learn and what to learn.  However, many of us seldom think enough about how we learn.

The objective of this session is to find answer to this question.  Register and attend these events happening in two different cities.  Even though the dates are the same for these conferences, registration are happening and only few seats are left!

I look forward to presenting,  interacting and learning from these two events!

I have elaborated my presentation in these two sessions in these two blog posts.

  1. Tutorial on Effective Dashboards: Takeaways and References
  2. My Session at Scrum Gathering India 2013 

Sunday, July 14, 2013

Effective Dashboards: Communicating Your Project Status

In the previous post, I mentioned about my upcoming tutorial ‘How to Build an Effective Dashboard for CXOs,Senior Management, and Business Leaders’ at the Annual Conference of Software Process Improvement Network, Bangalore Chapter (BSPIN Annual Conference 2013).  I am writing this post to share with you a very simple but an interesting aspect about communicating project status in status reports or dashboards.

How do we communicate project status?  In many organizations and project teams, I have come across the usage of traffic lights -   ‘Red’ - ‘Amber’ - ‘Green’.

 
Do you know? Using traffic lights to indicate project status is not a great idea because of two reasons.
  1. Project status is more than traffic lights.   In general the status of software projects do not turns suddenly from ‘Green’ to ‘Amber’ or from ‘Amber’ to ‘Red’.  Also, all ‘Amber’ projects do not mean the same ‘Amber’ and all ‘Red’ projects do not mean the same ‘Red’.  That’s why we come across the question ‘How Red is Red?’ - sounds familiar?
  2. Even if you prove to me that the statuses of your projects are as discrete as Green, Amber and Red, it is very important to consider those who are color-blind.   10% of males and 1% of females are color-blind.  When you include traffic light in your status report, this is how it appears to them.

Project Weather Reports
Learning from alternate sources can help us in coming up with a better representation of project status.  For example let us consider weather reports.  At a high level, weather status is categorized as ‘Sunny’, ‘Mostly Sunny’, ‘Partially Cloudy’, ‘Cloudy’, ‘Rainy’, and ‘Severer’. When we represent project status using this scheme, we have more than three level of classification and each of them can have a clear meaning and hence can help us do the right things. This is what Johanna Rothman says in her article ‘Sunny Skies or Storms? – Project Weather Reports'.


Project Status: Is it Binary?
Some of us claim that project status is binary – especially in case of agile projects.  The project moves forward in short iterations and we know if something works or does not work.  It is either ‘Green’ or ‘Red’.  Do you think it works that way?  Think!

Building effective dashboards involves many challenges.  What to know more? You are welcome to attend my tutorial, ‘How to build anEffective Dashboard for CXO’s, Senior Management, and Business Leaders’ at BSPIN Annual Conference 2013, Bangalore on 26th July 2013.

Takeaways and References
Do you want to download white papers and presentations (PDF files) to learn more about how to build effective dashboards?  Read 'Tutorial on Effective Dashboards: Takeaways and References'.   Happy Reading!

Saturday, July 6, 2013

How to Build Effective Dashboards

My next speaking session is at BSPIN Annual Conference 2013, Bangalore on 26th July - I am going to conduct a half day tutorial titled 'How to Build an Effective Dashboard for CXOs, Senior Management and Business Leaders’.   The preparation is on.  I am writing this post to collect your inputs, understand your questions, and collaborate with you.   Your inputs are going to enrich this tutorial.

What does a dashboard mean to you? The dashboard of your project, program or organization - Is it a sleeping pill or a nightmare? Or is it an effective dashboard? What is your role? - do you create or consume dashboards? This tutorial is going to start with these questions and explore several interesting aspects.

Let me stop questioning and provide a brief on this tutorial.  Dashboards, when built right, can become powerful decision making tools for stakeholders at different levels such as CXOs, senior management and business leaders.   Creating an effective dashboard starts with collection, consolidation and presentation of meaningful metrics to consumers.  This has to be carried out by considering the organizational strategic objectives and vision.  This is where the fundamental concepts of ‘Business Score Card’ add value to dashboards.  A scorecard based approach provides for a balanced or holistic treatment to the process of dashboard design.  In addition to this it is imperative to consider the business needs of various groups of stakeholders and deliver them the right set of parameters or metrics because a single dashboard cannot serve the needs of all stakeholders.  Dashboard is what stakeholders will depend on as their starting point to understanding business from a point of view which is appropriate to them.  An effective dashboard is something what provides them relevant information and saves their time from seeking more data points from additional sources of information.

This tutorial is to systematically analyze and learn the process of building effective dashboards.  Organizations in IT industry are people-intensive with multiple service lines and project types.  The role of ‘Quality Head’ or ‘Process Head’ and her/his team in designing and providing dashboards to business leaders involves continuous collaboration and deep thinking with several internal groups such as project teams, CIO organization, as well as senior leaders.  This is because dashboards are one of the primary sources of information that influence decision making in senior leaders.

Is this a topic of interest to you? If yes, what questions do you have? In your current role, what do you expect to see in an effective dashboard? Do you have any interesting experience or thoughts about the utility of dashboards? Please share.

Note: Early bird registration for this conference is on.  Visit http://bspin.org/conference2013/ for more details.

How do you represent project status in your status reports or dashboards?  Do you use traffic lights ('Red', 'Amber', 'Green') to represent project status?   Learn why that is not a good idea and the two reasons.  There is a better ways of representing project status!  I have explained it in the next post!

Takeaways and References: Do you want to download white papers and presentations (PDF files) to learn more about how to build effective dashboards?  Read 'Tutorial on Effective Dashboards: Takeaways and References'.   Happy Reading!

Photo courtesy: The picture included in this post is an edited version of a photo shot at an ethnic jewelry shop by my colleague Rama during our team outing in Goa this year.

Thursday, June 27, 2013

Metrics and Measures: What’s the Difference?


What is the difference between ‘metrics’ and ‘measures’? While answering this question, I am going to stay away from ‘text book’ definitions or differences on these two terms and I am going make it experience-based.

For people on the ground who are typically 'hands-on' team members,  ‘measures’ and ‘metrics’ are synonyms. Yes. For most of them these are synonyms. Those who write code or test code do not make a big deal of differentiating these two terms. They say, “Let us get the work done first, measure what matters, analyze, improve and move on.”  Some of them do understand the differences but they do not keep it all along and focus on those differences.

For Software Quality Analysts or Process Specialists, Researchers, Teachers etc., these are two different terms.

Whether that is an appealing answer to you or not, I think it is worth reading further and appreciating what these two terms mean to us in simple terms.

You measure certain things in software projects. Examples include effort, size (such as Function Point), number of review defects, number of testing defects, etc. When you combine or consider multiple measures to infer something, it becomes a metric. Examples include productivity (FP per Person Day), or cost of quality (COQ). Measures are fundamental (or raw data). Metrics are derived and help us in sense making and planning the next course of action.

Here is a simple example - weight and height of a person are measures and Body Mass Index, which is a function of height and weight, is a metric.

Metrics help in decision making. Metrics are expected to exhibit certain behavior. For example, productivity of a team is expected to remain steady or increase over a period of time under all general circumstances. Measures are collected but not analyzed in isolation in all general circumstances. Nor are they bound to exhibit certain behavior.

It is not that simple. Something which you perceive as a ‘measure’ can be a valuable ‘metric’ to someone else. For example, for a development manager who is working with a team and moving closer to the production release every measure matters. “Why have we taken 18 hours to fix this defect?” is not a reactive question. And, “Let us not react. Let us look at the average hours to fix defects. The numbers are not modulating at all. We are within limits” is not going to pacify either.  Right?

Obviously the way different stakeholders see and treat metrics and measures when the battle is going on and the way they do it after the battle is over are different. After the battle is over, some of those stakeholders and a new set of experts analyze, infer, interpret, extrapolate, and predict what is going to happen in the next battle. We fight different battles at different times. That is why, in order to win, understanding these differences is the first step and selecting the right set of measures and metrics is the next.

There is more to it. One topic is classification of measures and metrics. You will find different classification of measures and metrics at the website of National Institute of Standards and Technology.

Do you have any other points to add here?