|Its high time that we stop using Velocity (Venkatesh Krishnamurthy)
Fri, 24 Apr 2015 20:16:00 +0000
Velocity in an Agile environment is the most misused-used and misinterpreted word/metric. The key issue is, teams and stakeholders interpret Velocity as a productivity measurement rather than capacity of the team.
I don’t blame the team or the managers. But the “word” itself. If we look at the synonyms for Velocity(see the screenshot below), all of them point to quickness, momentum, acceleration, which naturally encourages people to connect this with “productivity”.
Google for Acceleration or Velocity and one would find following images… These images push people to think more of a competition, race and winning rather than a team work or a capacity.
I think we should stop using the word velocity and start using the word that creates some mental image to show the “team’s capacity”.
Do you think this is a fair call ?
|Coaching intervention during a team conflict (Venkatesh Krishnamurthy)
Wed, 15 Apr 2015 05:42:00 +0000
Every team goes through some stages of conflict before they stabilize. Leaders need to be conscious of intervening during such conflicts. The knee-jerk reaction of a typical leader observing a conflict is to jump immediately to “fix” the problem. It is highly recommended that they avoid it and take a step back to monitor the situation first.
The leaders need to find the appropriate time and context to intervene for coaching. Here are some examples and contexts.
1. Self-organizing teams are in the process of learning. They are trying to check the boundaries and positioning themselves in the team. Conflicts in such situations are imminent. The leader or a coach assigned to the team should avoid intervening in such contexts.
These teams are like butterflies emerging from pupa. Yes, there is a bit of process, pain and time involved to emerge out of pupa, and one needs a bit of patience. Trying to expedite the process could actually kill the butterfly.
2. Research suggests that creative and innovative work actually needs healthy debate and conflict. Intervention is needed to help the in understanding the differences. There are many times a person or a small group within a large group might be thinking tangentially. This could lead to conflicts and it does not mean that there is anything wrong here. In fact, such conflicts avoid groupthink.
For example, an engineer embedded in a marketing team obviously think differently. The engineer could be considered as a trouble maker as he/she is different than the rest of the marketing team. In contexts like this, the leadership or coach intervention is essential to assist the group.
As a leader one needs to drill down a little bit, get rid of the noise and study the type of work before intervening. The diversity of the team needs to be taken into account while dealing with a creative team as well.
3. If the team is working on a routine and repetitive kind of work, coaching intervention trying to facilitate discussions could backfire. Instead, a root-cause analysis with a management intervention is critical for smooth functioning.
To conclude, if you see or hear a conflict, don’t jump to fix the problem. Try to understand the context first. Many a times, the conflict is actually good for the team, and the organization in the long run.
|What is Agile’s Biggest Shortcoming? (Naresh Jain)
Sat, 11 Apr 2015 07:31:05 +0000
I’m surprised when people think Agile is perfect and if there are any shortcomings, its not the problem with Agile, instead, it is the person/team/org’s understanding or implementation issue. Some where along the way, the aspect that “We are uncovering better ways of developing software” was lost and agile became this static, rule-based prescriptive and dogmatic […]
|Overcoming the Obstacles to Achieving Agility and Delivering Business Value (Venkatesh Krishnamurthy)
Fri, 10 Apr 2015 00:38:00 +0000
I am excited to say latest version of Cutter IT Journal has published my article “Overcoming the obstacles to achieving agility and delivering business value” . I authored this article exclusively for Cutter.
In this article, I have articulated various issues that hinders agility in the organization. I am proposing the Systems thinking approach to solving the organizational and agile challenges.In order to achieve true agility, it is not sufficient to blindly follow the agile practices but to think beyond Agile. One should look at fixing the organization structure, focus on uplifting the relationship between business and IT and last but not least, fix the funding model.
I have shared some practical tips and solutions to achieve true agility beyond practicing Agile. The article is exclusively available for Cutter IT members and could be downloaded from here.
Here is the abstract of the article:
This months issue covers the following topics, including mine (highlighted)
IN THIS ISSUE
Vince Ryan and David Putman open the issue by exploring several common difficulties experienced by groups moving to an Agile approach. These range from cargo cult behavior -- blind adherence to the what of Agile without knowing the why -- to the technical abilities of people to work in an Agile environment. The authors delve into key issues such as empowering people to actually make the changes required to support Agile, as well as ensuring that they have the proper skills to be able to thrive. The authors explore such areas as training, the recruitment of new people, and offshoring/outsourcing with respect to the changes that may be needed for an organization to truly reap the promised rewards of an Agile approach.
Our second article, by Cutter Senior Consultant Lynn Winterboer, examines one of the less traveled paths of Agile -- the implementation of Agile approaches in the DW/BI space. Winterboer addresses the challenges of breaking this type of work down into small slices, when it has traditionally been an "all or nothing" deal. She describes what is perceived as technical inefficiency in the small slice approach and how that is balanced by the business efficiency. Winterboer shows not only the advantages gained by earlier delivery of value, but also the effort required and "instability" incurred during the transition. In the end, both organizations in her case studies found ways to deliver smaller aspects of the total solution, providing more value sooner to their stakeholders.
In "Overcoming the Obstacles to Achieving Agility and Delivering Business Value" Venkatesh Krishnamurthy dispels the myth that "Agile is a tool" that can be discarded when you're "done,"much as a hammer is put away once a construction project is completed. He asserts, correctly in my opinion, that simply following Agile practices does not make an organization Agile. The use of systems thinking to view the transition in the context of the whole organization shows how the organizational structure, funding models, and business/IT relationship must change in order to support true business agility.
Finally, Alan Shalloway speaks of how Agile and Lean have "lost their shine" as the result of misapplication. My experience certainly supports this assertion. Shalloway proposes the use of a Lean-Agile hybrid approach that leverages both the organization-wide strengths of Lean and the team-level strengths of Agile. Like Krishnamurthy, he recommends the use of systems thinking in order to take a more holistic view of the context in which the Lean-Agile transition is taking place. Shalloway describes this ecosystem and the unexpected effects that can result when you don't consider groups outside of the development teams.
Read more about this issue here
|Do you have an Agile Testing mindset ? (Venkatesh Krishnamurthy)
Wed, 08 Apr 2015 14:11:00 +0000
Here is my recent guest post for Zephyr…
Performing Testing in Agile projects is not termed as Agile testing. Agile testing involves whole different mindset. Then, how do you know your team has Agile testing mindset? As a coach, I start this by asking testers the following few questions:
- Do have to wait until the development is done to start testing?
- Do testers feel there is a lack of time at the end of Sprint?
- Are testers blamed when defects are identified?
If testers answer “Yes” to some or all the questions above, then the team still has “Waterfall” mindset in guise of Agile.
Another litmus test to try is to check the team’s wall which is popularly called “Kanban” wall. If you see a wall like the one below, where the “Test” ing is a separate column, then this is a smell.
Read the rest of the article on Zephyr
|Need for dedicated testers in Agile environment (Venkatesh Krishnamurthy)
Wed, 11 Feb 2015 04:52:00 +0000
Here is a short article for Zephyr’s guest blog
Scrum recommends 3 roles, the Product Owner, Scrum Master and the team. There is no dedicated role as a tester (or QA) if you are following pure Scrum.
Agile also recommends that the team members are expected to be cross functional with T-shaped skills popularly known as “Generalized Specialists”.
However, the challenge I have seen in many projects is how “generalized” one could be while performing the role. Most of the projects are, so budget and time constrained that everyone is part of the rat race. They just want to get things done, and there is hardly any time for the team members to learn from each other and building generalized skills.
Building cross-functional and T-shaped skills is not easy. It needs a dedicated attention, time, effort and $ is involved from the organization to enable this. One cannot ask a developer to sit with a tester for a few days and learn testing. Personally I believe that testers mindset is something that comes with passion. In addition, mindsets of developers and testers are different.
There is one more reason behind having dedicated testers, and this is due to “IKEA effect”. The Harvard article concludes that,
“When people use their labor to construct a particular product, they value it more than if they didn't put any effort into its creation, even if it is done poorly.”
In the context of this article, when developers create the code, they value their creation more than the testers. The developer doesn’t like someone finding fault with their creation. This is one of the reasons why one gets to hear all sorts of excuses from the developers.
Read rest of the article here
|Done with Definition of Done or Definition of Done Considered Harmful (Naresh Jain)
Mon, 26 Jan 2015 12:26:49 +0000
Definition of Done (DoD) is a checklist-driven project management practice which drives compliance and contract negotiation rather than collaboration and ownership. Its very easy for teams to go down rat-holes and start to gold-plate crap in the name of DoD. It encourages a downstream, service's thinking mindset rather than a product engineering mindset (very output centric, rather than outcome/impact focused.) Also smells of lack of maturity and trust on the team. Bottom line: Its a wrong tool in the wrong people's hand.
|Melbourne: Upcoming Agile trainings and conferences (Venkatesh Krishnamurthy)
Sat, 10 Jan 2015 21:24:00 +0000
The Agile community is getting ready for a new and exciting year ahead. Several interesting and fascinating Agile trainings, conferences and workshops have been scheduled.
Here is the first list:
1 - Advanced Agile Master Class with Alistair Cockburn. 17-19 February
2 - Certified LeSS (Large Scale Scrum) Practitioner with Bas Vodde. 24-26 February.
3 - 1st Conf, 16 March 2015. For people starting out with agile. Alistair Cockburn keynote.
4 - Workshops for 1st Conf, including Introduction to Kanban, and Management 3.0 … with more coming.
NB - The code POBA will apply a discount to all of those events :)
|Scrum Australia 2014 : Build great products with Scrum + Design Thinking + Lean Startup (Venkatesh Krishnamurthy)
Thu, 01 Jan 2015 10:43:00 +0000
I had the privilege of speaking at Scrum Australia 2014 conference couple of months ago. It was a fascinating experience to stand in front of such an energetic and knowledgeable audience and share ideas. Scrum Australia team had put a lot of effort and energy in getting good speakers not only from Oceania but from abroad as well. I enjoyed every bit of this conference for 2 days.
The title of my topic was “Building products that customers love by strengthening Scrum with Design Thinking and Lean Startup methods” .
I believe that we need to combine various methods, and use their strengths to build the products. Scrum has its own strengths, and similarly Design Thinking and Lean Startup as well. However, none of these methods on their own can be used on their own to build great products.
First of all one needs to ensure that any new product idea is viable, desirable and technologically feasible.
It is very important that one has a good understanding of the problem one needs to solve. Most of the products fail mostly because of lack of understanding of the problems.
Design Thinking comes handy in articulating the problems, and Lean startup could be applied with product testing, pivoting.
I would like to thank Lynne Cazaly for beautifully depicting my session with the following “Visual Note”
I had put together this idea of bringing the 3 methods together (Scrum + Design Thinking + Lean Startup) long ago. This idea was published by Cutter as an Agile advisor. Cutter was also gracious enough to make this article public. The entire article is available here if any one is interested in getting into a detail a bit.
I have been attending Scrum Australia conference without fail since the last couple of years, and return with a load of new knowledge and experience. I am already looking forward for the 2015 conference :-)
|Correlation does not imply causation (Venkatesh Krishnamurthy)
Thu, 11 Dec 2014 05:26:00 +0000
Popular ideas being borrowed in the Agile community include the Spotify’s tribes/guilds, Google’s 20% innovation time and many more. In this advisor, I am challenging the readers to think before they act and understand the hidden secret’s of success.
Here is link to the complete article.
This advisor has been written to enable the Agile conferences attendees to look deeper about the “causation” aspect rather than the “correlation” .
|Self-Organised vs. Self-Managed vs. Self-Directed…What’s the Difference? (Naresh Jain)
Wed, 29 Oct 2014 04:17:56 +0000
Self-organised, self-managed and self-directed…do they mean the same thing or are they actually different concepts, where one might be more desirable over the other? In the context of an “agile” team, people seemed to use these terms interchangeably. However, it’s important to note that there are subtle, yet worthwhile distinction between each. Self-Managed Team A […]
|Program Committee’s Expectation from a Talk Proposal when Selecting It (Naresh Jain)
Sun, 12 Oct 2014 11:36:51 +0000
Over the recent conferences, I’ve had several people ask me the follow: I would like to better understand the expectations from the organising committee on the talk proposals. In particular, I would like your feedback on my talk submission so that I can work on improving the same. I think, this is a very valid question: […]
|How to make wall-related decisions in Distributed Agile projects (Venkatesh Krishnamurthy)
Thu, 09 Oct 2014 04:41:00 +0000
I authored the following article for Cutter which got published today. So, it is hot out of the press.
The subject that every distributed Agile team is questioning is the topic of setting up visual walls. Conflicts arise when purists argue in support of setting up visual boards across all locations, while the distributed teams consider it an inconvenience.
Many companies don't realize the importance of making the right decisions related to visual walls. Typically, wall setup is left to the ScrumMaster. These companies don't realize that this "single-handed" decision could result in loss of productivity, increased stress levels, and thousands of dollars in loss due to waste.
==== I am recommending a principle based approach for deciding if the information needs to be displayed on Physical wall or Digital wall. ===============
Wrong wall decisions or forcing wall decisions on a team could end up with stale walls and thousands of hours could be wasted in maintaining these walls. Be sure your organization considers the core principles during its exploration of walls.
Since this article is available only for Cutter Members, kindly continue reading rest of article on Cutter
|If you are start up, think beyond one user (Venkatesh Krishnamurthy)
Wed, 08 Oct 2014 06:22:00 +0000
As I am coaching and mentoring a few start ups in Melbourne and elsewhere, I have noticed common pattern of issues across the board.
Recently read a story about startup failure “Patient Communicator”. The founder built fantastic features applying iterative development method, however, it was never tested beyond his father’s medical center.
If you are in start up journey, think beyond one particular user !
|Key Principles for Reducing Continuous Integration Build Time (Naresh Jain)
Fri, 03 Oct 2014 08:23:37 +0000
Many teams suffer daily due to slow CI builds. The teams certainly realise the pain, but don’t necessarily take any corrective action. The most common excuse is we don’t have time or we don’t think it can get better than this. Following are some key principles, I’ve used when confronted with long running builds: Focus on the Bottlenecks – […]
|2005-2015 Copyright © Agile Software Community of India|
|Website designed and hosted by Agile FAQs|