In the recent times the following ideas/buzzwords are getting filled with the void of struggling, adolescent Agile
1. Holacracy : Read more here from Zappos example.
2. Real Options Theory : Read more here
3. For scaling Agile: SAFe(Scaled Agile Framework) is already popular, Craig’s LeSS(Large Scale Scrum) and now ScALeD
Photo Courtesy: Flickr
I will explain this through a simple example of how culture gets created in organizations.
The answer to that question can be found with root cause analysis (RCA), which helps to divert attention from people to process improvement.
Typically, agile teams are recommended to do an RCA session in response to issues raised during retrospectives. Shamefully, many agile teams skip RCA and continue to struggle in a whirlwind of issues.
RCA is not rocket science—especially when we have such a simple tool as the five whys. Eric Ries has elaborated on RCA with some practical examples from his lean startup journey. Here’s an example of a simple Excel spreadsheet that shows how to conduct RCA using the five whys; you can download a ready-to-use spreadsheet here.
Read the complete article on Techwell
Photo attribution: ThinkReliability
In this recently published Cutter article, I discuss the importance of understanding Agile as a tool rather than as a goal. I am also proposing some ideas from complexity theory and Cynefin framework to substantiate the need for parallel/safe to fail experiments rather than handcuffing organizations with single framework/method or a process.
Read the complete article on Cutter
Photo courtesy: Flickr
One of my friends is a very successful tennis coach, however, he sends his kids to a different coach. This was interesting, and I asked him why can’t he teach his kids. His response didn’t surprise me at all. He said, kids take parents for granted and some times, they listen to outsiders more intently.
I see a similar pattern at work as well. Some times, employees listen to a highly paid external consultant rather than an in-house expert or supervisors.
Why is that ?
I googled around to find some research or articles around this kids behavior, and I found this interesting article. The author gives the following 3 reasons behind kids behind deaf to their parents:
Applying the above reasons in the context of organizations, I see that employees don’t listen to organizations when organizations don’t listen to them. Is this a reasonable hypothesis ?
On a similar note, I have seen another “Celebrity bias”. I have seen some tweets from celebrities tweeted and favorited by hundreds. But the same information published by a lesser known person does not get noticed much. For example, if Seth Godin or Richard Branson say something and if a common man “X” says exactly the same thing, then people tend to believe celebrities more than a common man.
Why do we have this celebrity bias ?
Many people attribute this to “Halo Effect” . Some good stuff from the article below…
As you read above, the halo effect can influence how teachers treat students, but it can also impact how students perceive teachers. In one study, researchers found that when an instructor was viewed as warm and friendly, students also rated him as more attractive, appealing, and likeable.
Marketers take advantage of the halo effect to sell products and services. When a celebrity spokesperson endorses a particular item, our positive evaluations of that individual can spread to our perceptions of the product itself.
Job applicants are also likely to feel the impact of the halo effect. If a prospective employer views the applicant as attractive or likeable, they are more likely to also rate the individual as intelligent, competent, and qualified.
So, the next time you trying to make an evaluation of another person, whether it is deciding which political candidate to vote for or which movie to see on a Friday night, consider how your overall impressions of an individual might influence your evaluations of other characteristics. Does your impression of a candidate being a good public speaker lead you to feel that she is also smart, kind, and hard-working? Does thinking that a particular actor is good-looking also lead you to think that he is also a compelling actor?
I had the privilege to Co-Author my first book “Who is Agile in Australia and New Zealand” with Renee and Sunish . This book is available for purchase from here
This book is a collection of interviews with passionate Australia & New Zealand agilists who answer the following questions:
1. What is something people usually don’t know about you but has influenced you in who you are?
2. What would have become of you, if you were not doing the job you do today?
3. What is your biggest challenge and why is it a good thing for you?
4. What drives you?
5. What do you think makes a great team?
6. What is the essence of Agile?
7. What is the last book you have read and which book made a huge impact in your life?
8. If you were going to have a dinner party with anyone alive or deceased - which three people would you invite and why?
9. What is the one piece of advice you would give to someone just starting with Agile?
10. What question do you think I should also ask and what is your answer?
11. Whom do you think we should ask next in Australia and/or New Zealand and why do you feel they should be included in the book?
Based on the original "Who Is Agile" book, this book is a regional version for Australia & New Zealand. Whether you’re a novice or an Agile Guru, this book is going to help you learn a bit about the people behind the names & get their perspective on Agile.
Organizations generally go with copying the practices/strategies from other popular brands/companies with the assumption that it works for them. In reality, it won’t. Every practice is context dependent, and since each company is different the strategies adoption should be different.
In this Cutter article, I write some of the secret ingredients that fuel the strategies. Check this article out: http://www.cutter.com/project/fulltext/advisor/2014/140306.html
According to Peter Senge, “People don’t resist change but resist being changed”. As human beings we change almost every day. Whether it is getting married and living with a new person or a new born baby adjusting to the changing environment by learning things. People change when they perceive the change satisfies their needs and fulfills their wishes.
From the change agents perspective, It is very important to provide as much information as possible from different angles while suggesting change. Typically, the vision for change gets initiated by the leadership and change agents are roped in to implement them.
Based on my experience, I see the following obstacles that derails changes.
1. Unclear goal
2. Goals with no way to track
3. Change agents with no access to visionary. This is a major issue as the vision gets diluted while being passed from one layer to the other
4. Benefits of the change shared only through the business angle. People who are supposed to change will keep asking, What is in it for me ?
5. Looking at a quick fix rather than a sustainable change
I could enlist many more challenges !!
Before I conclude, I invite you to watch this good video about overcoming resistance to change.
Photo courtesy: http://flic.kr/p/7e1XGT
One needs to understand the skills and mastery needed to succeed as an agile coach. The agile coaching competency framework provides the guidelines, criteria, and pathways for an aspirant. Knowledge is one part of it, but listening skills are even more important. Coaches need to be aware of their own listening skill level and strive to reach level three.
Change could be brought, not by listening but by asking powerful questions (PQ). Even though there are several resources about PQ available on the Internet, I would highly recommend reading Co-Active Coaching.
Continue reading this article here to learn more about Arc of conversation and Asking powerful questions.
When you have a chance check this link out to read all my articles on Techwell.
Tools and technologies are an essential part of any distributed Agile development. Companies invest thousands of dollars in procuring high-fidelity video conferencing equipment at their onshore locations. However, one thing they nearly always ignore is the integration capability with their offshore locations.
Continue reading rest of the article on Cutter ….
This kind of stress and expectation is not uncommon in the IT world. The same pressure trickles down from the top to the delivery teams, spreading the negative effects throughout the company.
Many organizations don’t realize that putting undue pressure on people forces them to make more mistakes rather than helping them perform better. Whether it is running a project or a company, the cost of stress in the workplace is more damaging than the benefits.
The European Agency for Safety and Health at Work clearly describes that stress is due to the demand-and-supply gap. In a software development environment, the demands could be to deliver the working software on time and within budget using available resources. Most of the time, however, the budget and resources are inadequate to meet the demand, resulting in stressful situations.
Continue reading rest of the article about managing stress at workplace here on Techwell
About the Author
Rajaraman Raghuraman has nearly 8 years of experience in the Information Technology industry focusing on Product Development, R&D, Test Data Management and Automation Testing. He has architected a TDM product from scratch and currently leads the TDM Product Development team in an IT MNC. He is passionate about Agile Methodologies and is a huge fan of Product Development, Agile Development and Agile Testing. He blogs at AgileDevTest Blog. He is also an author of a free Ebook "Programmer's Motivation for Beginners". Connect with him on Google+
In my own thoughts, I will share some attitudes which a great developer should have apart from the general expectations of being technically and analytically sound, understanding requirements in detail, good design skills, etc.
Attitude #1 - A bug is a question of my ability to write good code
Fixing bugs is part and parcel of a software developer's activities. A bug is obviously the worst enemy of a Developer. But how many developers think in the following lines while fixing the defects
· What I could have done to avoid this bug in the first place?
· How did I allow this bug to escape my eyes?
· OK, something wrong has happened this time. How do I avoid the same mistake next time? What steps do I need to take?
Truth is very few developers think on those lines.
A person willing to be a great developer should consider a bug as a threat to his position, as a threat to his credibility, as a threat to his programming skills. That is the attitude that will make him/her a great developer.
Attitude #2 - Mr. Tester, I challenge you to find bugs in my code
How many developers have this attitude? Many developers think that the job of the testers is to find bugs. Yes. Obviously, but that doesn't mean as developers, we can take bugs for granted.
A great developer or a person willing to be a great developer should
always invite / challenge the tester to find bugs in his/her code. He should have so much confidence in his code that he can challenge in such a way.
Attitude #3 - No compromise on code quality
Code quality should be of prime importance to a developer. That will include following the right coding standards, making the code more maintainable using proper design and code refactoring, etc, etc. But how many of us compromise code quality for many reasons best known to us?
I can quote an instance in my project to explain this. I was leading a team of developers and we were working on fixing something in the very last hours of a Friday night. We had to give a build on Monday. All of us were looking into the problem. I got curious as I saw the problem and started getting my hands dirty in the code. Time went by and only the last 5 mins were left for everyone's cab. It was a make or break. We had to come the next day, if that was not solved today. I did something at that time, which absolutely infuriated all my team members. Unable to see the clarity in the running code, I refactored a bunch of lines at that last minute. Everyone were so pissed of, that they started scolding me :-) asking if it was so important at that moment. I answered "Yes, it is that important". Of course we worked the next day for other reasons, but the whole point was even though I had an option of fixing the code in the running code, I chose to refactor the code not compromising on the code quality.
A great developer or a person willing to become a great developer should never compromise on the code quality, no matter what.
Attitude #4 - Confident but not arrogant
A great developer or a person willing to be a great developer should be absolutely confident of his abilities but should not be arrogant towards fellow developers and testers. He should always remember that he is part of a team that is working towards a common goal of shipping a project on time with good quality.
Attitude #5 - Acknowledge the Tester
It can happen that despite all the hard work and efforts put in by the great developer, a great tester can still find defects in his code. In those cases, acknowledge the great tester.
A great developer or a person willing to be a great developer should always acknowledge the tester for the bug that he found. He/she should remember that the bug is the enemy, and not the tester :-)
With this I conclude this post, hope you find it informative. Thanks for the read. Cheers.
If you found this post useful, please share it with your friends. You can also stay updated with the latest blog post by simply submitting your email id to the right in the section "Get Updates by Email"
If you liked this post, you will also like my free Ebook "Programmer's Motivation for Beginners" which is available at http://programmersmotivation.com.
I am happy to share that one of my articles Agile Maturity Assessments: Boon or Bane? has been made it to the Top Agile articles list in 2013 on Cutter.
Here are the list of top 6 articles:
by Jens Coldewey
There is a conception in the public debate that Agile is a basically undisciplined approach. Book titles such as Balancing Agility and Disciplinefuel this perception. In a debate on Agile and CMMI we had earlier this year, Cutter Senior Consultant Hillel Glazer rightly pointed out that "it would be incongruous to ignore the plentiful examples of dreadfully undisciplined 'Agile' adoptions resulting in 'Agile in name only'" (see "'Agile vs. CMMI': The Debate Goes On").
by Israel Gat
The beauty of Agile software methods is that they enable us to focus with a singularity of purpose on the iteration management and project management aspects of the software delivery process. Numerous other aspects of software delivery, such as those shown in Figure 1, are, of course, of critical importance. Yet, it is the sustained and continuous focus on how we perform iteration management and project management that leads to eventual success with Agile.
by Rob Thomsett
This Executive Report outlines a major Australian bank's four-year journey from using Agile models for some software development projects to an enterprise-wide agility model in responding to and delivering change, all in an effort to completely commit to agility transformation across the organization. The report presents five key lessons relevant to all organizations and to which all businesspeople interested in leveraging and broadening the true power of the Agile revolution must pay attention. The report also examines various practical approaches to the issues each of these key lessons raise. These approaches have worked successfully at the bank, despite a major reorganization during the past year.
by Venkatesh Krishnamurthy
In the last two decades, organizations have moved from applying waterfall toward embracing Agile methods. However, one thing that has not changed much during that time is measuring the maturity levels. ThisAdvisor offers some tips and techniques for improving the Agile maturity assessment process.
by Scott Ambler
Your initial instincts for how to run an outsourced project are likely to hurt you more than help you. Outsourcing introduces a collection of risks that can be uniquely addressed with a disciplined agile strategy. Luckily, the Disciplined Agile Delivery (DAD) process decision framework provides a foundation from which you can tailor a viable strategy for disciplined agile outsourcing. In this recorded webinar, Senior Consultant Scott Ambler explores strategies for effectively initiating and governing an outsourced IT delivery project in an Agile manner.
by Jim Plamondon
This Executive Report introduces the API Economy to CxO-level executives of industries outside IT. It follows a novel dialogue format, as if it were a transcription of an introductory consulting session with the CEO and CIO of a fictional company in the oil and gas industry. The report defines API and the API Economy, discusses some of the many API business models, argues that this economy extends a proven software architecture onto the Internet, presents that architecture as a tool for thinking about business models, and discusses the role of developer relations in making APIs successful. The report then applies these ideas to the task of solving one of the fictional company's billion-dollar business problems using an API-based approach.
It is very critical to understand that people abandon websites and move on if it takes more than 3 seconds to load. Inspite of having all these data, IT departments are still struggling to get some grips on application performance testing (PT).
In this article, I would share the 3 critical factors for building a successful PT strategy. In a typical waterfall project, the performance testing was done at the end of code freeze. However, Agile methods recommend performance testing during every sprint. My experience has been that every conceivable problem in a software project starts at the beginning, mostly because of ignorance. This includes PT, as well.
Photo courtesy flickr
For a successful execution of PT, enough time and energy needs to be spent during Sprint 0. This energy should build a strong foundation of skills, automation and strategy as shown in the picture below.
Let us look at contribution of the above 3 areas during PT.
continue reading the article here on
Below are some of the steps my personal trainer took when he consulted with me, followed by my comments to bring the idea of coaching teams into perspective. You’ll find that there is a strong correlation between what I learned during my training endeavors and what constitutes good team coaching.
1. Understand requirements: The first question the trainer asked me upon signing up for the fitness program was about requirements. Do I need to lose or increase weight or build muscle?
Coaching lesson: It is important to understand the customers’ requirements before starting any coaching assignment. It is not safe to assume that everyone needs cheaper, better software. Ask as many questions as possible before delving into the next step.
2. Inquire about health: Once the trainer was happy with the requirements, he inquired about my current health. He did a quick blood check and a blood-pressure test, in addition to taking my height and weight measurements.
Coaching lesson: Don’t jump into coaching without understanding the current health of the system. Understand team morale, culture, leadership style, and relationships. Have one-on-one meetings with key players to understand their feelings, ideas, and thoughts.
3. Recommend the right equipment: Based on the above information, the PT recommended four pieces of equipments I should use, and demonstrated their use. This moderate regime recommendation was tracked through a daily register.
Read rest of the article on Techwell here..
Couple of months ago, more than 70 bloggers came together and shared their opinion about “What Project Management meant to them”. It was a highly successful event with a seamless virtual collaboration. As an outcome of the event, a fantastic book “PMFlashBlog” has been compiled and published.
I am happy to share this book here on my site and feel free to download it from here. Don’t forget to read my contribution on Page 67 of the ebook :-)
Many thanks to Allen Ruddock for compiling the book and Shim Marom for conceiving the idea.
According to Jeff, the role of a product owner is similar to that of the product manager. The product owner is responsible for building a valuable, usable, and feasible product. It is a shame that most product owners in Scrum projects are treated as domain experts, tasked with handling and prioritizing requirements. Forget about usability; many POs in companies don’t even have the visibility about the budget allocated for the project.
Many companies have dedicated production support or “maintenance” teams, whose duty is to focus on quickly fixing the defects from the production systems. Many companies run like this—like a factory. The green field teams keep churning code, deploy it to production, and then hand it over to the support team for further maintenance.
This separation of the coding and maintenance teams is a highly dysfunctional way to work. The above system absolves the PO from ownership, thus orphaning the product. The real ownership is generated when the team developing the code maintains it as well.
Backlog grooming was discussed in the workshop as well. These grooming sessions are popularly used by product owners and the Scrum team to plan the next sprint.
Read the rest of the article here
It seems there are several ingredients that everyone seems to agree on for building SO teams.
A good leader is an essential ingredient in SO teams. Mike Cohn shares some vivid examples of how leaders should monitor the behavior and fix team issues. Giving a free hand to the team members or allowing them to do whatever they want won’t result in an effective SO team.
The leader should have servant-leadership qualities, as well. As Jim Highsmith says, implementing a light-touch-leadership style is essential, and decision making should be delegated to the lowest level possible.
Read the rest of the article here
I have stepped into my 12th year of practicing Agile methods. Started with XP before embracing Scrum, Lean, Kanban. I nearly thought we found some solution, but looks like we still have some more things to do. Even now, organizations are looking at Agile as a silver bullet without fixing the root causes.
Here is the issue, the issue is Agile was born mostly to banish the problems coming out of the Waterfall model. If you don’t believe me, have a look at the manifesto (screen shot on the left), everything on the right side is all about the waterfall way of working. Whether it is the overreliance on Tools, Processes or documentation. Everything on the left hand side is supposed to be the Agile way of working. There is nothing wrong with it, but it is applying the band aid on the issues coming from the right hand side. It looks like there was too much focus on solving the problems coming out of waterfall rather than the focusing on software delivery. I see that Agile ended up becoming just a band aid.
Why Agile is just a band Aid ?
Couple of years ago, when every one was overwhelmed with the project failures applying the waterfall model, people wanted to get rid of this problem. Instead of fixing the problem, people started applying the band aids against the bruises, and the problem stayed back. In the above analogy, the waterfall was more like a bruise, and it was not the real problem.
As we know, the band aid would reduce the bleeding and provide some short term relief. However band aid won’t stop the accidents from happening again.
What is the real problem ?
I see that the issues that was bothering the business and development community couple of years ago was much bigger than just the waterfall. The issues were org structure, leadership styles, complexity of the problems, etc. Waterfall was just a tip of the iceberg. Even now, half of the Agile projects are going through a lot of struggles, and it has been proven repeatedly that Organizational culture and communication issues are the key reasons for failed Agile projects. (See other issues in the screen shot below)
Once again, we need to remember that Agile is not going to fix the company philosophy, Agile is not going to improve the communications. Agile, Lean and Kanban are all the band aids. The cultural issues and organizational philosophy issues, communication issues are like the accidents that keep happening and causing scratches again and again.
Unless we fix those issues, no matter what methodology we follow, the projects end up with failures and teams continue to stress out.
You can keep applying the band aid but how long ?
It is important for delivery experts to focus more on fixing the accidents rather than keep applying the band aids.
All of us are doing what we are doing to achieve one thing, that is the happiness. I read this inspiring article a while ago “Searching for happiness: What makes life meaningful” ?
We dream of living in a villa with swimming pool and Jacuzzi. We want to live next to a river surrounded by picturesque mountains. Why do we need these things ? Its because, imagining having these amenities gives us a sense of happiness. We think that one day by acquiring them we would be in a “permanent” state called “happiness”. Is this really possible ?
Personally, I feel that happiness is a journey and a state of mind. There is no permanent state called “happiness”, and a person gets happiness by conquering challenges. No challenge and no happiness. So, happiness is an ongoing exercise of chasing challenges, conquering and experiencing it. I get happiness when I spend time with loved ones or some one writes some good words about an article. I get happiness when I clear the challenging “driving test” or complete a presentation in front of “challenging” audience.
Now, let us look at how Agile and Happiness are related…
I see a lot of organizations craving for Agility, and it reminds me of human beings craving for happiness. The organizations invest a lot of money to become “Agile". This is akin to the the waterfall era where organizations used to crave for CMM certifications. During the waterfall era, the companies thought having CMM 5 certification would enable them to reach kind of “Nirvana” or a “final state” of excellence. Anyways, now it is history that it was proven wrong.
With the popularity of Agile, the companies are now craving for the Nirvana called “Agile”. When 4 Agilists from 4 different companies get together, they would always discuss if their company is “Agile” or not. They talk about Flickr doing 10 deployments a day, compare it to their own and beat themselves up . There is a perception that if a company is able to do “10” deployments per day or do a Continuous Integration then they are an “Agile” company. This is very similar to human beings assuming that they would be in a state of “permanent” happiness when they acquire house and Jacuzzi, living next to the river. Is this really true that there is a final state called “Agile” ?
I personally think that, being “agile” is truly what makes a company as “Agile”. Just like how happiness is a journey and there is no “permanent” state called happiness, being “agile” is a journey and there is no final/permanent state called “Agile”.
As long as the company is going through a journey of continuous improvement and moving in the right direction, they are “Agile”.
