Upfront Thinking Is Like Insurance

Insurance is great for all sorts of things. I have health insurance in case I become ill or injured. I have auto insurance that will repair or replace my vehicle if it's damaged. It also protects me in case I am involved in an accident that harms someone else. I have life insurance so that if I die, my wife and daughters are taken care of.
These are types of insurance I've chosen to have. There are other types of insurance I've also chosen not to have. For example, I've personally chosen not to have dental insurance. Most years that works out great for me. But there are some years when I have a big bill and wish I'd paid for the insurance. But, overall, I've been happy with that decision.
Similarly, every time I buy a plane ticket online there's a little checkbox asking if I want to buy travel insurance. I think it covers me in case I get sick right before a flight or something like that. I've never bought that and I've never regretted it. I've also flown over 2 million miles. So forgoing that type of insurance has also worked out well for me.
So insurance is great. I can't imagine going without my health insurance. But other types of insurance can be thought of as calculated gambles, which is exactly what they are. And sometimes those gambles pay off, sometimes they don't.
We can think of upfront thinking on development projects in the same way we think about insurance. Like insurance, upfront thinking is a way of paying a little today to avoid paying a lot tomorrow.
Upfront thinking on software projects can take a number of forms. It can be someone thinking about the architecture of the system. It could be a UI designer sketching wireframes. It could be an analyst building detailed scenarios and confirming all manner of edge cases conditions through workflows. Or it could be a database designer thinking about the structure of the database. I'm not saying any of these are bad (or that they're good). They are merely examples of upfront thinking.
Some projects will benefit from some amount of upfront thinking (although perhaps not all forms at once that I've just listed), just like many of us benefit from having some types of insurance.

How Much Upfront Thinking Is Enough?

An important consideration is how much upfront thinking is enough. The best way to determine this is, unfortunately, in hindsight. But use the level of upfront thinking you do on current projects to help you decide how much to do on future projects. Here's how ...
Suppose your team finishes a project and they never had to reverse a decision. Every decision was made perfectly the first time. I'd say that team overinvested in upfront thinking. They over insured.
Consider instead a team that finishes their project and only had to reverse one decision. But it was a major decision and caused a total re-architecting of the system. That team underinvested in upfront thinking. They underinsured.
Finally, consider a team that finishes the project and had to reverse a lot of little decisions. None caused big re-architecting, but there were a lot of little decisions that each caused rework. On their own, each is small. But added together, it was a lot. Again, here's a team that underinvested in in upfront thinking. They were under insured.
So, as projects progress, evaluate whether the team is having to occasionally backtrack on decision and architectural decisions. They should occasionally have to do so. If they never do so, they've over invested in insurance by doing too much upfront thinking. But, if they're backing up too much or in big ways, they have underinvested and should do more upfront thinking.

How to divide and conquer User Stories

The other day I had a conversation with a colleague on Such little snippets about writing stories. At one point we came to talk about to split user stories. I'm a big proponent of user stories max is 1-2 team business days. My experience is that this gives the stories that are easy for the team to over / through and therefore they can come up with a good and fair estimate.
 

Visible Signs that you need to split your story:

• The team expresses great risks in the form of new technology or external dependencies.
• There are many concrete acceptance criteria. It determines itself what many are, but my guess is more than the 10th
• It takes you more than 5 minutes to explain the essence of Story to the team.
• The team estimate more than 5 story points. 

 

 

Stories Rate

When you break a story, it often occurs that the total estimate rises. It might seem like a silly idea to split now when it comes to "cost" more! 

A high estimate is the uncertainty. Then an estimate of 13 does not just mean 13 story points bum! This means 8-20 story points. Most go to get as accurate plans as possible, so therefore gives a splitting sense. And it may well be that on paper it looks like a bad deal for the PO but he achieves is security. Security to estimate holds. Security that he gets what he wants and that gives business value. And who would not like to have it.
 
So you exchange a small estimate of great uncertainty for a larger estimate of low uncertainty.
 
So my advice to you as Product Owner is to make sure that you make small manageable stores, for both the team's and your own fault. The extra work is well spent.
 
Happy splitting!



Reference : http://blog.devoksne.dk/user-stories-del-og-hersk/

Scrum Master Skill Set

i was going through some article on Aglie Scout and found this very interesting skill set of Scrum Master which become very near to my heart so i plan to share with my readers 

 Top 10 Personal Skills for a Scrum Master:  

• Servant Leader – Must be able to garner respect from his/her team and be willing to get their hands dirty to get the job done

• Communicative and social – Must be able to communicate well with teams
• Facilitative – Must be able to lead and demonstrate value-add principles to a team
• Assertive – Must be able to ensure Agile/Scrum concepts and principles are adhered to, must be able to be a voice of reason and authority, make the tough calls.
• Situationally Aware – Must be the first to notice differences and issues as they arise and elevate them to management
• Enthusiastic – Must be high-energy
• Continual improvement - Must continually be growing ones craft learning new tools and techniques to manage oneself and a team
• Conflict resolution - Must be able to facilitate discussion and facilitate alternatives or different approaches
• Attitude of empowerment - Must be able to lead a team to self-organization
• Attitude of transparency – Must desire to bring disclosure and transparency to the business about development and grow business trust

Technical Skills:

• Understand basic fundamentals of iterative development
• Understand other processes and methodologies and can speak intelligently about them and leverage other techniques to provide value to a team/enterprise
• Understand basic fundamentals of software development processes and procedures
• Understand the value of commitments to delivery made by a development team
• Understand incremental delivery and the value of metrics
• Understand backlog tracking, burndown metrics, velocity, and task definition
• Familiarity with common Agile practices, service-oriented environments, and better development practices

*The above technical skills are nice-to-have, but not necessarily required!

Scrum Master as a Servant Leader

 Character and Servant Leadership: Ten Characteristics of Effective, Caring Leaders


In an article, Larry Spears explains that a good servant leader has 10 characteristics that are of critical importance:

Listening

The servant leader must be willing to listen and identify the will of a group. Hearing it will give him the opportunity to clarify that will. The leader must be able to listen and reflect on what is being said; this is an important aspect of being a servant leader.

Empathy

Empathy is quite an important characteristic for a servant leader to have. A servant leader must accept and recognize the special and unique spirits that exist in each different person. They cannot reject coworkers and colleagues as people, even in difficult conflict situations. A successful servant leader is a great empathetic listener.

Healing

This can be considered one of the strengths of a servant leader: The power of healing one´s self and one´s relationship to others. Servant leaders understand that they can take on a special role within their team/group. They have a special power to fix relationships.

Awareness

Awareness helps people to become stronger. Awareness helps the servant leader to understand issues involving ethics, power, and values. This characteristic helps any servant leader to be able to view situations from a more holistic and integrated position.

Persuasion

A good servant leader tries to convince others, instead of forcing compliance. Usually a successful servant leader is great at building consensus within teams.

Conceptualize

Transforming a big vision into small workable pieces that everyone understands is a great characteristic servant leaders generally have. They have the ability to pick up on daily problems and conceptualize solutions that are understood by everyone.

Foresight

A great servant leader has the capacity to foresee the likely outcome of even the most difficult situation. Using previous experience and present data, they can predict with great accuracy the future outcome of a situation.

Stewardship

Servant leadership involves an inherent commitment to serve the needs of others. It also emphasizes the use of openness and persuasion, rather than control.

Commitment to the Growth of People

Servant leaders believe in true intrinsic motivation. They believe that all people have a lot to contribute to the organization. A great servant leader is committed to helping people to grow within the organization.

Building Community

Building a community among those who work within a given organisation is the last characteristic of a great servant leader. They believe they can create true communities among the people that work within the same organization(s).

Ref: lmsgoncalves.com/2014/08/04/scrum-master-servant-leader/

QA Role in Scrum Team

Role of QA in Scrum is much more than just writing test cases and reporting bugs to the team.

Contrary to the synchronous activities of a traditional Waterfall project, Scrum expects development activities to be performed in the order they are needed – i.e. asynchronously. This break from tradition raises a common question by many of the clients, developers, and business stakeholders who are new to Agile – “How can testing professionals engage effectively during a sprint before anything has been built?” this Post will focus on QA role in agile testing and the place of importance they hold on a Scrum team. Much of what I have learned through about the roles and responsibilities of QA on a Scrum team I will be sharing with you throughout this article. 

More Than Just Building Test Cases

On traditional Waterfall projects the QA role is only involved at the very end of the project – once all coding is complete. On these projects, the QA role would typically be given a requirements document and the completed code and would be expected to write and execute test cases which verify that the application does exactly what the requirements document says. However, the QA role in Scrum is not just about executing test cases and reporting bugs.

On a Scrum team the QA Analysts participate and fulfill a variety of responsibilities conjointly with other team members. They are involved right from the very beginning of a project where they work closely with business analysts and developers. In Scrum, the QA role is not a separate team that tests the application being built. Instead the Scrum team is a cross-functional team where developers, business analysts and QAs all work together. Apart from building test cases, QAs can also help the Product Owner (PO) write acceptance test cases by playing the role of proxy product owner. Having QA fill in as a proxy for the Product Owner when they are not available helps keep the team moving forward at all times. They can also interact with the Product Owner by asking questions and challenging assumptions to help clarify the business requirements. 

Participate In Estimating Stories

Quality assurance analysts are typically very good at creating test case scenarios based on user requirements. They also excel at identifying and capturing complex and negative test case scenarios. In fact, they are typically much better at it than developers, who tend to focus mostly on the “happy path” of the user story. Including testers during Release and Iteration Planning, when user stories are estimated, can help the team think beyond the happy path. This helps the team produce a more realistic estimate since both “happy” and “unhappy” paths have been considered. Estimation is a tough task and it is good practice to have the whole team participate in coming up with the estimate.

Help Keep Vision And Goals Visible

As the team works through the testing and stabilization activities, QAs should take the lead to plan, organize and involve the whole team in the testing work and to keep people motivated just as the Scrum Master (SM) does. Since very few developers enjoy testing work, the QAs , along with the Scrum Master, must make the testing vision and goals visible to the whole team and help to keep the motivation level of the team high. Sometimes it helps to be creative when testing scenarios require help from developers or other team members. Try making the testing activity fun by using amusing test scenarios, funny test data, fun competitions, etc. Do what you can to help the team enjoy and contribute to the testing work. 

Collaborate With Customers And Developers

One of the primary responsibilities for the QA role is to provide feedback from their testing experience to the Product Owner as well as collecting feedback from them. QAs work closely with the Product Owner to help them develop detailed acceptance criteria for their user stories. Based on what the team learns during each sprint, QAs can also help the Product Owner modify or enhance existing user stories to better reflect the true requirements.

On occasion, the quality assurance analyst may be asked to act as a proxy for the Product Owner. In these situations, QAs and developers will sit and work together as a team to help improve the quality of the project. The QAs can pair up with developers for writing unit test cases and for discussing acceptance criteria. The more these roles work together, the greater the shared clarity will be on requirements. The increased clarity that results from working together will reduce the questions and doubts developers often encounter during coding time, which produces greater efficiency and a big time savings for developers and testers alike.

The whole team should be expected to pitch in and assist with testing whenever required based on the needs and the availability of team members. This practice helps create balance in the team and a shared responsibility for getting the work completed. It also helps produce the required pace to move faster with early testing feedback and increased quality. 

Provide Fast Feedback

The build-test-fix cycle that traditional Waterfall teams repeat endlessly produces a lot of extra work for the team and usually ends up wasting a lot of time. This activity is much simpler in Scrum as QAs and developers work together throughout the entire process. Developers can consult the QAs about acceptance criteria or the expected behavior of any functionality from the user's perspective while working on the feature, which results in saved testing and bug fixing cycles. 

Automate Regression Testing

It is often said that automation is the tester’s best friend since it provides repeatability, consistency, and better test coverage over the software’s functionality. This is particularly true on a Scrum project with small sprint cycles of 2-4 weeks, since QA generally has even less time to test the application. During each 2-week sprint, QA must perform full functionality testing of the new features being added during this sprint as well as perform full regression testing for all the previously implemented functionality. As would be expected, this responsibility grows significantly with each passing sprint so any automation that can be applied to these tests would greatly reduce the pressure the QAs feel.

Automated tests are particularly helpful in providing rapid feedback when teams implement Continuous Integration (CI). Each time there is a new build, the automated tests can be executed and provide immediate feedback as to whether the new features are working correctly or whether there have been any regressions of previously working functionality. Without automation, QA must perform these tests manually, which becomes a very monotonous and error prone task. Automation can help detect the defects early and give QA more time to explore the edge cases of the new features being developed. Automation can help QA deliver testing work much more efficiently and effectively. 

Participate In Release Readiness/Demos

At the end of each sprint, the team holds a Sprint Review meeting where the team must demonstrate the user stories completed during the sprint to the Product Owner and other interested stakeholders. This Sprint Review meeting provides a healthy dose of accountability to the team and motivates them to complete as many user stories as possible.

With small sprint cycles of 2-4 weeks, everyone on the team must stay focused on his or her respective tasks in order to complete them on time. Developers stay busy developing their assigned user stories and fixing bugs while QA stays busy writing test cases, clarifying questions from Product Owners, and automating previous sprint stories. Having short sprint cycles also means that developers have less time to explore the complete functionality of their user stories on their own. As a result, developers typically consult with QA to better understand the user stories since they are the ones aware of the complete functionality and know each and every requirement and acceptance criteria. As a result, it can be a good practice for QA to perform the demo at the Sprint Review meeting and field functional questions coming from business. That can free up the developers to handle any technical questions that surface. 

Analyze User Requirements

QAs are the proxy product owners of the Scrum team. QAs are generally good at understanding the business requirements from the user's perspective since they are often asked to use the application as the end users would. QA can help provide feedback to the Product Owner based on their testing experiences and can help the Product Owner better understand the application from the end user's point of view. 

Enforce the Definition of Done

Having a clear Definition of Done (DoD) is important to a Scrum team. A DoD is nothing more than a simple list of team defined completion criteria - all of which must be completed before the user story can be considered done. This list typically includes things such as writing code, performing functional and regression tests, and gaining the approval of the Product Owner. A very simple DoD might include the following:

• Code Complete
• Unit Test complete
• Functional / UI Test Complete
• Approved by Product Owner

While it’s not the sole responsibility of QA to define the DoD, it is often QA’s responsibility to monitor the work being performed by the team and to ensure that each completed user story meets the benchmark DoD. An efficient Scrum team will review their DoD before starting each new user story to make sure they know what is expected. A team’s Definition of Done is not static and may evolve over time as the Scrum team needs evolve. DoDs can be defined for sprints and release as well. 

Always Plan Testing With Testing Strategies

Since there is not a test lead or even a specific test team in Scrum, building a test plan or following specific test strategies on a Scrum team can be an issue. Scrum believes in preparing only enough documentation to support the immediate needs of the team. As such, QA will prepare just enough high-level documentation for test strategies and plans to guide the team. Since there are no QA leads in Scrum, the QA analyst typically decides the test strategies. 

Tester and Analyst Roles Converging

On Scrum teams it is common to see the responsibilities of QA and those of the business analyst begin to converge. The Business Analyst role is typically responsible for creating and maintaining the sprint and product backlogs, analyzing the user stories from the business perspective, and prioritizing the backlogs with input from the Product Owner. The QA role, on the other hand, is typically responsible for defining / refining the acceptance criteria for each user story, testing the completed functionality each sprint from the end user's perspective, and ensuring all previously completed functionality has not regressed. As QA tests each user story and verifies the defined acceptance criteria has been met from the end user's perspective they are also analyzing the user stories in term of the business as well. So, in many ways the QA role and the business analyst role share many of the same responsibilities, required skills, and overall objectives.

Normally, a Scrum team gets their user stories and the pre-defined project scope from the Product Owner at the beginning of a project. However, in Scrum the team is encouraged to suggest new features or changes to existing features if it will improve the end users experience. The team is also encouraged to recommend changes to the priority / sequencing of user stories in the backlog when they find technical dependencies that suggest a different implementation order would be more efficient. Whether its defining requirements, analyzing user stories, defining / clarifying acceptance criteria, building acceptance test cases, or closely working with customers, the roles of tester and analyst are clearly converging. While this offers many advantages – particularly for small teams - it also has its disadvantages as well. The biggest concern is that neither the tester nor the business analyst role will get as much attention as it would with a team member fully dedicated to that responsibility.

Conclusion

While QA Team member still write tests and report bugs, they also support many other roles and responsibilities on the team. They are an important part of the team and are involved in the project right from the very beginning.

Working as a QA Analyst on a Scrum team for the past two years has been a great experience and has provided many learning opportunities. I have filled many different roles and responsibilities including QA analyst, proxy product owner, helping developers write unit test cases, acting as the team's quality conscience, and keeping track of problems and software bugs. In short, this experience has added many wonderful skills to my toolbox and has helped me learn how to play many different roles – all at the same time. Most importantly it has taught me to ask questions rather than just follow the documentation and do whatever it takes to help the team succeed.

While QAs still write tests and report bugs, they also support many other roles and responsibilities on the team. They are an important part of the team and are involved in the project right from the very beginning.

This Article is inspired from Priyanka Hasija Article on "QA Role in Scrum".

Programing Languages Infographic

I was busy with my new Project but during my busy schedule i found some time to look at this interesting info-graphic i am sure it will be useful in future reference.


Info-graphic by Veracode Application Security

Scrum Tiger Teams and others

Scrum teams are “Tiger Teams” for everyday work

There’s a term I’ve been hearing a lot lately: “Tiger Team”. Ostensibly these teams are more aggressive, tenacious, skilled – maybe even more agile – than an ordinary team. But every time I hear the term, I wonder: “Then what are your normal teams – Kitten Teams? Teddy Bear Teams? “. Because if you need some extraordinary project or circumstance to form a team so unusually effective that it deserves such a namesake, it doesn’t speak well for your regular state of play. What it is about all your other projects that doesn’t deserve the same treatment? Are they worth doing at all?

A Scrum team is a “Tiger Team” without the pretense of exceptionalism. It’s a cross functional team of representatives with all the skills and domain knowledge necessary to solve a problem autonomously – hey, what a concept!   As our long-term partners at Intel put it, a Scrum team is “…a task force without the crisis”.  Instead of a crisis, we have urgency provided by short timeboxes; Instead of needing an emergency to use what we know is the most effective way to work, we make it a routine; and instead of high drama providing the emotional impetus, we have frequent and regular reward of seeing progress being made.

So I’d like to hear less of Tiger Teams, and more of boring old cross-functional, empowered autonomous Scrum teams, routinely churning out business value. Don’t your products deserve it?

 

article belong to : http://blogs.collab.net/agile/scrum-teams-are-tiger-teams-for-everyday-work

5 Reasons indiviusals Fail to achive Goals

Why do some people achieve their goals while others fail? I believe it's because successful people manage to overcome five barriers that, in many cases, guarantee failure. Here are those barriers and how to overcome them:
1. Uninspiring Goals

When most people set goals, they envision a "thing," such as a particular amount of money, an object (like a new car), or a specific achievement (like writing a book). Unfortunately, these "things I'm gonna get or do" goals don't appeal to the core of what motivates you, because they miss the point that what you're actually seeking in life and work is the POSITIVE EMOTIONS that you believe those things will produce.

Fix: Rather than envisioning a "thing" as your goal, envision--with all the strength in your imagination--how you will feel when you achieve the goal. That way, you'll be inspired to do whatever it takes (within legal and ethical bounds) to achieve that goal.
2. Fear of Failure

If you're afraid of failing, you won't take the necessary risks required to achieve your goal. For example, you won't make that important phone call, because you're afraid that you'll be rebuffed. Or you won't quit your dead-end job and start your own business because you're afraid that you might end up without any money.

Fix: Decide--right now!--that failure, for you, is a strictly temporary condition. If things don't go the way you'd like, it's only a setback that, at most, delays your eventual success. In other words, accept the fact that you'll sometimes fail, but treat that failure as an unavoidable (yet vital) component in your quest.
3. Fear of Success

In many ways, this fear is even more debilitating than the fear of failure. Suppose you achieved something spectacular, like enormous wealth. What if it didn't make you happy? What then? What if you ended up losing all of it? What then? Would your friends start acting weird? Would your family be envious? Such thoughts (and they're common) can cause even a highly motivated person to self-sabotage.

Fix: Decide that you're going to be happy and grateful today and happy and grateful in the future, no matter what happens. Rather than focus on possible problems, envision how wonderful it would be to be able to help your friends and family achieve THEIR goals. (Hint: Watch the last season of the TV series Entourage!)
4. An Unrealistic Timetable

Most people vastly overestimate what they can do in a week and vastly underestimate what they can do in a year. Because of this, most people try to cram too many action items into the short term rather than spacing out activities over the long term. The inability to get all the short-term steps accomplished creates discouragement and the impression that the final goal is slipping away.

Fix: As you list the activities and steps required to achieve a goal, schedule only the 20% of the activities that will produce 80% of your results. (I explain more about this in the post The Secret of Time Management.) Beyond that, set ambitious long-term timetables, but always leave some "wiggle room" when you plan short term.
5. Worrying About "Dry Spots"

It's easy to get discouraged when you reach a point at which nothing you do seems to advance you toward your goal. For example, suppose you're trying to master a certain skill. You make swift progress at first but then, after a while, it seems as if you're not doing any better, or maybe a little worse. Some people use these "plateaus" or "dry spots" as an excuse to give up and therefore fail.

Fix: Whenever you reach a plateau or dry spot, it's time to celebrate rather than give up. A plateau is almost always a sign that you're on the brink of a major breakthrough, if you just have the patience to stick with it and trust that you'll eventually achieve your goal.

Do not try to Agile Scrum When you don't know what is Agile Scrum

Agile is not a playbook. It’s not a set of directions. It’s not a checklist. It’s a mindset and a culture – and it needs buy-in across an entire organization in order to succeed. 


i need to share some Few Reasons why Scrum Fails from an Article by Mike Brown on utest Blog as below:

Old Habits Die Hard

Based on my observations and those of several noted experts, Agile seems to “fail” whenever it’s forced on a team or organization that is accustomed to other methods. After years of developing and testing in a certain manner, one cannot expect an entirely smooth transition. Want proof? Here are a few results of a recent survey that interviewed 200 companies that had recently transitioned to Agile:

Out of over 200 participants, 64 percent said that switching to Agile Development was harder than it initially seemed. Forty percent of respondents did not identify an obvious benefit to the practice. Out of those who did, 14 percent thought it resulted in faster releases, and 13 percent – that it created more feedback. Seven percent of participants noted that Agile developers were happier due to reduced future planning and documentation.

According to Voke, since the global financial crisis of 2008, the average cost of software projects has seen a sharp rise, even though developer teams have become smaller and the deadlines tighter. Meanwhile, the risk of software failures associated with Agile Development has remained high.

“While many people assume that Agile is faster, better, and cheaper, actual results vary greatly. Many organizations are diving into the Agile movement without a clear understanding of what it is, and what the consequences of adoption may be. They may not realize that today’s solutions are tomorrow’s problems,” said Theresa Lanowitz, lead analyst at Voke. (link)

I think it’s fair to say that the process of “going Agile” must be clearly explained and outlined (more on this shortly), otherwise your development practices will change, but in name only.


“I don’t think most people need convincing about agile principles, even if they’re just attracted to the idea of frequent delivery,” said Nate Oster, an Agile Player-Coach and Founder of CodeSquads LLC. “In practice, however, a lot of waterfall behaviors survive by hiding behind the new agile jargon. If we want different results, it’s not enough to change our jargon, we have to actually change the way we collaborate!”

He continued: “I think the deep-down objection to agile is that it challenges our hidden assumptions. A lot of our cherished ‘best practices’ from waterfall are actually optimizations of ‘our job’ – they make us ‘efficient’ but actually undermine the agile goal of frequently delivering high quality software as a whole team.”

In terms of waterfall legacies, Nate gave me the example of how some test teams still request that a feature be 100% complete before it’s ready to be tested.

“That’s a verification mentality, a holdout from waterfall when it was the tester’s job to efficiently find all the bugs,” he explained. “On agile teams, we prevent those bugs by specifying the feature as a team using testable examples, then we build those behaviors in small slices. When we work in small increments like this, we test continuously instead of at the end. That’s how we prevent ‘mini-waterfall testing.”

So is making an Agile transition impossible? Not at all. Is it difficult? Yes. Is it necessary? Here’s what Agile expert Scott Barber once had to say on the matter:

I believe that the trend to “go Agile” is misguided. If a company is developing good software, the people involved in developing that software are happy working there, the software development is sustainable, and the business is being adequately served by that software, there’s really no need for them to try to be more or less Agile. Agile has challenges like any other culture, but the single biggest challenge I find is companies trying to solve development, process, management, and/or schedule problems by “going Agile.” Teams who have grown up in a culture that is fundamentally different than Agile simply will not find it easy to “go Agile.”

Unrealistic Expectations

Another reason why Agile sometimes fails has to do with unrealistic expectations of the Agile actually is and what it can help you achieve. Agile is commonly believed to be a set a practices, processes and tools, when in fact, Agile is really more of a mind-set and culture.

Processes vary depending on the company, the product and the personnel, so it’s no surprise that they sometimes fail when they are misapplied. A mind-set and culture, on the other hand, can transcend those factors. Here’s a good analogy of this problem from Scott Ambler (emphasis added):

Would you take the same approach to create a web page describing your family and the embedded software for a NASA space probe? Of course you wouldn’t. What about a business application and a NASA space probe? Likely not. Would you take the same approach with a team of six people that you would with a team of sixty people? Or six hundred people? Once again, likely not. Different situations obviously call for different approaches.

It’s easy to see that you need to take a different approach developing a web page as compared to developing a space probe. Your company likely doesn’t develop both web pages and space probes, so it’s easy to stand back and recognize that there’s a difference. It would be clearly foolish to follow similar approaches on these projects – a very simple process is sufficient for the web page development effort whereas a complex and rigorous process could be appropriate for the space probe. You would put the space probe project at serious risk following the web page process and you would incur significant costs following the space probe software process to develop your web page. Clearly it is important to follow the right process.

Basically, if you expect Agile to perform miracles or instantly transform your software development process, then you’re likely to view the method as a major failure.

Department Fragmentation

What happens when a development and product team adheres to the principles of Agile, but the QA team does not? Conversely, what happens when a QA team wants to be involved early in the dev process, but the engineering and product teams resist? What happens when executives want everything to be Agile even if they don’t really understand what it means?

“When I hear ‘we have an agile test team,’ I think that’s a contradiction in terms,” said Oster. “If all they do is test, then they’re not really an agile team. Agile teams frequently deliver high quality software, and that includes testing. An agile ‘feature team’ needs all the skills it takes to deliver software, and that includes programming, analysis, and testing skills, regardless of who performs these tasks. I love it when new agile team members start cross-training outside the role on their business card. Mature agile teams know there isn’t a sharp line between ‘my job’ and ‘your job.’ There are just tasks we need to complete, and everyone brings different skills to the table, so that we can complete them as a whole team.”

As mentioned previously, Agile is not a playbook. It’s not a set of directions. It’s not a checklist. As Scott Barber said, it’s a mindset and a culture – and it needs buy-in across an entire organization in order to succeed . Here’s a great presentation by Agile coach Mike Cottmeyer that explains the importance of agile being adopted by multiple departments

Giving Up Too Easily

As we’ve covered, the transition to Agile isn’t easy. I’m sure every department thinks they have the steepest climb, but since this is a testing blog, we’re going to focus on the QA department and its ability (or lack thereof) to move to an agile process. As Nate Oster points out, the problems of the agile transition have less to do with Agile and more to do with existing practices.

“In my experience the biggest challenge with adopting agile is how it just relentlessly exposes what we’re not very good at yet, and in a lot of organizations, that includes testing,” he said. “When the goal is frequently completing new features, that forces teams to work in small batches with short timeframes, so agile exposes how traditional testing is optimized for ‘throwing a big pile of code over the wall.’ Traditional testing is really a broken system, because these huge piles of work arrive late in the game.”

When trying to adopt Agile practices, there will be a ton of excuses as why it won’t work. Those who understand the real benefits of the approach – and genuinely want to make the transition – will likely have success. Those who are searching for reasons why it will fail – well, they will likely find them and either abandon the effort entirely or end up practicing what i calls “fake agile.”

The SCRUM Blog: Your Scrum team's velocity and how to misuse it.

The SCRUM Blog: Your Scrum team's velocity and how to misuse it.: Your team has a velocity, whether you choose to measure it or not is irrelevant. On an average day, your team decreases the amount of work t...

Steps and Techniques for the Scrum Implementation

      from my learning i came to understand that if you want to evaluate at which level Team or Project is in Scrum check the list of Steps and Techniques implemented in your Team and Project.

• Relative estimation
• Test driven development (TDD)
• Acceptance test driven development (ATDD)
• Automated Unit Testing
• Automated System Testing
• Automated Acceptance Testing
• Automated Regression Testing
• Explicit Definition of Done for Stories
• Explicit Definition of Done for Iterations
• Explicit Definition of Done for Releases
• Definition of Done includes quality goals
• Pair programming
• Peer code reviews
• Product Backlog Grooming
• Social contract/working agreements
• Continuous integration
• User stories
• Up front architecture

The Case Against Agile: Ten Perennial Management Objections

Steve Denning, Contributor from RADICAL MANAGEMENT: Rethinking leadership and innovation


If at first an idea is not absurd, there is no hope for it.

–Albert Einstein

The general reaction within the Agile world was naturally strongly positive. Finally, mainstream management is getting it. “Next step -> Rule the World!”

There was somewhat less enthusiasm from the traditional management camp to having the world ruled by Agile. The most complete—and revealing—response from the traditional management camp came from a link submitted by PM Hut and written by Bruno Collet: The Limitations of Agile Software Development. The defenders of traditional management claim to be unafraid of being tagged as “behind”, “old school” or “just plain stupid”: traditional IT professionals know that “Agile has limitations.”

1. “Agile is only for stars”

“Agile was designed for experienced, smart, and high-achieving people like its creators, i.e. stars. You could give them any project, with any method, and they would succeed. Not every group can be motivated, experienced, and skilled enough to self-organize into an efficient team. We have to work with the staff we have. They need close supervision. So Agile is not for us.”

In other words, make do with mediocrity. Learn to live with the people who are either not experienced or smart or high-achieving. Hierarchical bureaucracy makes an assumption of incompetence and expects mediocre performance. It learns to live with mediocrity on a permanent basis, in the process creating—not surprisingly—the need for the layers middle managers to provide the “close supervision”.

Agile makes the opposite assumption: competence. It expects performance and forces action if it doesn’t occur. It assumes a workforce who know what they are doing and provides a transparent framework for them to show what they can do. If the group doesn’t deliver at the end of each short cycle, then that is painfully apparent to everyone—immediately, not years later when the project runs out of money and the software doesn’t work. Agile is a way of forcing either high performance or change.

Agile squeezes out mediocrity and requires high-performance. Hierarchical bureaucracy breeds incompetence and feeds off mediocrity: the organization performs accordingly. Faced with the choice between high-performance and the mediocrity, traditional management opts for mediocrity.

2. “Agile doesn’t fit our organizational culture”

“Agile is fine for startups run by kids with earrings, tattoos and blue hair. But in our firm, respecting the chain of command and job responsibility are keys to survival. It takes a couple of days just to go through the company’s policy manual. The narrow responsibilities, and rigid policies, processes, and one-size-fits-all methodologies of our firm don’t fit the free-wheeling ways of Agile. Agile isn’t going to work here.”

Precisely. What’s wrong here is the corporate culture, not Agile. Surviving in today’s marketplace requires individual and team freedom. It translates into cross-functional work that is constantly adapting, with roles switching as needed. It also mewans adjusting processes continuously to reflect the current situation.

In Agile, processes are secondary to the requirements of the work. Bureaucracy is the opposite: the requirements of the work—and the customer—are secondary to the bureaucracy. Not surprisingly, firms in this mode do a poor job of meeting customers’ needs.

When the culture doesn’t fit Agile, the solution is not to reject Agile. The solution is to change the organizational culture. One doesn’t even have to look at the business results of firms using hierarchical bureaucracy to know that they are fatally ill. In today’s marketplace, they will need to change their culture or they will die. They need to become Agile.

3. “Agile only works for small projects and our projects are big”

“Teams larger than eight are too big to be Agile. We are a large organization with large projects so Agile won’t work for us.”

It’s true that Agile requires small teams. The reality as Richard Hackman pointed out in his classic book, Leading Teams: Setting the Stage for Great Performances, is that all effective teams should be small. A big effective team is an oxymoron.

In any event, there are obvious solutions to coping with large projects by dividing the work into a number of relatively independent smaller subprojects then each part can be implemented by an agile team. As explained by Craig Larman and Bas Vodde in their book, Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum (2010).

4. “Agile requires co-location and our staff are geographically dispersed”

“Agile emphasizes that face-to-face, spontaneous conversation is the best form of communication. In some organizations, this isn’t possible. Moreover, work extends beyond the development team since other stakeholders such as business analysts also require interaction. Hence this limits the applicability of Agile.”

While it’s true that co-location is obviously ideal for Agile teams, where staff are dispersed, teams can use technology maintain open and continuous communication.

The reality is that distributed software development using Agile can be highly productive, as firms like Xebia have shown. See also the Larman/Vodde book for more discussion of distributed Agile teams.

5. “Agile lacks project management processes”

“Most agile methodologies do not define any project management processes. Whether we’re agile or not, we need to manage project scope, planning, budgets, strategies, and reporting. So Agile can’t be the answer.”

It’s true that Agile doesn’t solve all management issues. Agile solves a specific management issue, namely, how to combine disciplined execution with creativity and innovation.

As Bruno Collet helpfully points out, “Unless you choose an agile methodology that encompasses all needed processes, you should combine it with a methodology that define these processes and rely on agile for day-to-day team management.”

6. “Our firm’s individual accountability systems don’t fit Agile”


“Agile development stresses the importance of team ownership in order to improve teamwork and therefore overall results. But how can we implement team ownership when our organization’s performance-reward system assesses individual performance and rewards individuals, not teams?”

The answer is pretty simple: change the organization’s reward system. They are the problem, not Agile.

7. “Agile is just a fad”

“Here we go again. Another silver bullet! Another panacea! Another management fad!”

Again, let’s be clear. The article didn’t say that Agile was “the” solution to everything. It’s not a panacea. It’s not a silver bullet. What the article said was that Agile is the solution to a particular problem, namely, reconciling disciplined execution with creativity and innovation.

There are other management problems that the Agile Manifesto didn’t address. Some of those other management problems are discussed in Kent Beck’s talk discussed in Applying ‘inspect and adapt’ to the Agile Manifesto.

One important aspect concerns the goal of the organization. Agile teams that work in organizations where the goal is maximizing shareholder value are ultimately just as doomed as teams practicing waterfall. Sooner or later, the money-driven culture will crush even the successful Agile teams. Genuine Agile involves re-thinking the goal of the entire organization in terms of adding value to customers sooner.

8. “There are better ideas than Agile”

One critic said, “Introducing these ideas to management via the path of Agile software development doesn’t make sense. Much more interesting would be to introduce these ideas via things that make sense to non-software managers, such as beyond budgeting, complexity thinking, lean management and rightshifting.”

Ignoring the management experience of thousands of software development teams around the world is what doesn’t make sense. A better idea is a better idea, even if it comes from the “wrong” people.

The approaches of beyond budgeting, complexity thinking, lean management and rightshifting are helpful and obviously related to Agile software development, but it’s not obvious that they are having any more real success in changing the basic command-and-control paradigm of traditional management.

Rather than fighting internecine battles (e.g. Lean is better than Agile or Kanban is superior to Scrum), it would be more useful to see the commonalities in these various movements and join forces to get real transformation of traditional management.

9. “Nothing new here”

All of the individual components of Agile have been around for quite a long time. What is new is to put those elements together in a coherent and integrated fashion as in radical management.

10. “Not a fair comparison?”

“How can you possibly compare Agile to the discovery of longitude?” was one agitated answer to the first article which cited the historical examples where path-breaking ideas were rejected by the experts for decades, such as the sad experience of John Harrison who despite the scientists discovered a way to measure longitude.

Let’s be clear, first, that John Harrison, the Yorkshire carpenter, didn’t “discover longitude”. The British scientists of the 18th Century knew all about longitude. What they didn’t know was how ships’ captains could measure longitude in the middle of the oceans. They could measure latitude from the stars, but they couldn’t seem to find a way to read the stars so as to get a handle on longitude. So the scientists spent decades studying the stars trying to find the secret that “must be there”.

What John Harrison figured out was that the answer didn’t lie in the stars: the solution lay in having an accurate clock. With an accurate clock, you could take a reading from the sun at noon and figure out your longitude. The problem was that there weren’t any clocks accurate throughout a long voyage. So Harrison set out to invent one. When he had done it and shown that it worked on the long voyage from London to Jamaica, the scientists went apoplectic. They were upset that the solution to the problem didn’t lie in the fancy astronomy of the heavens that they had been studying for decades: it lay right under their noises with a simple clock. Very annoying!

In their frustration, the scientists refused to concede that they had been wrong and give John Harrison his well-deserved prize. It took an act of parliament—in effect, ordinary citizens—to give him his recompense: equivalent to over a million pounds in today’s money.

Something similar seems to be happening with Agile. The solutions that the experts have offered to the problem of reconciling disciplined execution with innovation have all tended to be various ways of increasing or modifying control over an increasing number of ideas—chief innovation officers (Debra Amidon), innovation “factories” (P&G), the innovation marketplace (Alpheus Bingham and Dwayne Spradlin), separate business units (Clayton Christensen), open source innovation (Henry Chesbrough) and shared value (Michael Porter and Mark Kramer).

What’s annoying about Agile to control-minded management practitioners and theorists is that it recognizes that the problem lies is control itself. The solution to reconciling disciplined execution and innovation lies in giving greater freedom to those people doing the work to exercise their talents and creativity, but doing so within short cycles so that those doing the work can themselves see whether they are making progress or not.

Even worse for hierarchical bureaucracy, Agile thrives on transparency. One of the dirty not-so-little secrets of traditional management is that control thrives on non-transparency. So introducing (real) Agile means exposing all of the non-transparent tricks that hierarchical managers play on their subordinates to maintain power. Is it any wonder that Agile isn’t naturally popular with the command-and-control gang?