INVEST in Good Stories, and SMART Tasks

This really interesting article by Bill Wake explains how to write good stories and tasks following the INVEST (Independent, Negotiable, Valuable, Estimable, Small and Testable) and SMART (Specific, Measurable, Achievable, Relevant and Time-boxed) models.

Here is the Youtube video if you prefer :)

Stop starting, start finishing

http://www.slideshare.net/jchyip/stop-starting-and-start-finishing

Subordinating the Scrum Team

From http://www.leadingagile.com/2010/05/subordinating-scrum-team.html


Agilists intuitively get that it's a bad idea to build an inventory of detailed specs way ahead of when they are going to get turned into software. Why? Because we know that as our product emerges, we are going to want to make changes to those requirements. There is a real risk that a lot of that work will end up being waste. That's a big part of why we document agile requirements as user stories... we want the placeholder now, but we don't need the details until we get closer to building that part of the product. It keeps our options open and our overhead low.

Building an inventory of requirements has a more insidious impact than just opening up the possibility of waste. Sure, we risk specifying stuff that the business might not need, but we also build in assumptions and risk that can't be validated. Everything that we define now, everything that can't be built and tested immediately after specification, represents something that we'll have to validate or mitigate somewhere down the road. Those uncertainties make it really hard to forecast when we are going to get to done. They make it tough to be predictable.

Furthermore, requirements gathering an analysis shouldn't be done in a vacuum. We know that we're going to want some help from our development team to discuss what's possible from a technology perspective. When we pull our team into meetings to discuss these things, we are taking their attention away from the task at hand. Our team is working on the highest priority features, and here we are pulling them away to help forecast lower priority requirements that may or may not ever make it into the product. It's a pretty solid formula for going slower than we have to.

Even though we may have some capacity to do the requirements work... and it would be nice to get ahead of the game a little... it is not something we generally do on agile projects. Managing all those requirements changes, tracking all those assumptions and risks, and absorbing all the productivity impact to the development team is just too great a cost. We KNOW it is going to cause us problems down the road. Any benefits we'd gain from getting ahead of the requirements work would be lost due to the overhead necessary to maintain our requirements inventory. That inventory slows us down and makes us more resistant to change.

We understand... in this kind of a scenario... that the team has to subordinate the requirements gathering process to the overall production cadence of the delivery team.

Now, let's extend this metaphor up a little and talk about our financial services company... and specifically our new hyper-productive Credit Card Processing Scrum team. With regard to the rest of the organization... our Scrum team is able to produce working software much faster than everyone else around them. The question we're dealing with is... SHOULD they produce working software much faster than everyone else around them? In this context, under this set of circumstances, I'm saying no.

I'm suggesting that the Scrum team in our complex product organization becomes very much like the requirements gathering function in our earlier example.

When the Credit Card Processing team builds software features faster than the rest of the organization can consume those features, they risk the possibility of waste and rework. They introduce assumptions and risks that have to be managed and mitigated throughout the life of the project. They will disrupt the other development teams around them and force those teams to multi-task. The other teams will be forced to pay attention to features that they won't be ready to build for another several months. All that code will slow us down and make us resistant to change.

While it is technically possible for the Credit Card Processing team to get a head of the game... and it might make them feel more productive... it might be great for their team morale... ask yourself what impact they are having on the rest of the organization. It might not be as positive as you think. So... for all the same reasons you might ask a PO or a BA to slow down writing requirements to fill the product backlog, you might want to ask your Scrum team to slow down building software until the rest of the organization can catch up.

It's counter-intuitive, but if you start thinking past the single team, it might be exactly what you need to do.

Agile Game Development : Agile Game Development Checklists

The Agile Game Development Checklists are meant to help drive discussion about the implementation and effectiveness of agile practices (including Scrum, XP, TDD and Kanban) for a team and stakeholders.

This first version contains a checklist for the ScrumMaster role. Revisit how this role adds value to a Scrum Team and how that role can be improved.
read more

Reduce Manual Test Technical Debt

When a team that has relied mostly or entirely on manual testing decides to adopt Scrum, it will quickly discover how hard it is to run short sprints when there’s a lot of manual testing to be done each sprint. It will also realize that unless it does something drastic, the technical debt will continue to accumulate. Teams in this situation can follow a three-step process to extricate themselves from at least the worst of these problems:

1. Stop the bleeding.
2. Stay current.
3. Catch up.

The first priority of a team with technical debt in the form of an over-reliance on manual testing is to stop the bleeding, stop things from getting worse. The best tourniquet is to find ways to automate some of what is being tested manually. To mix metaphors, teams should find the low-hanging fruit: tests that will be easy to automate but save a lot of manual effort. Brian Marick, a leading authority on testing and coauthor of the Agile Manifesto, has told me that “the real low-hanging fruit is often not automating some test execution but automating other testing tasks, like populating databases or automatic navigation to the page where you’ll start manual testing. You’re not reducing the number of manual tests, but you’re reducing the total time it takes to run them.”
After the bleeding has been stopped, the situation will no longer be getting worse from sprint to sprint. Manual tests still will be added each sprint but the team is finding enough low-hanging fruit each sprint to offset the time needed to run the new manual tests. At this point, it is time to move to step two: learning to stay current. During this phase, the team focuses on learning how to write and automate tests for whatever new features are added during the sprint. While doing this, no more debt is accumulating, so the situation isn’t getting any worse, but it’s not yet getting any better either. Learning to add automated tests in the same sprint as the feature will be a new skill for the team. It won’t be as hard to learn as the initial skills were during the first phase but will require new discipline.
Eventually the team enters the final phase, which is when it catches up on additional outstanding testing debt. I generally tell teams that I coach that I don’t care how quickly the outstanding testing debt is brought down as long as it is indeed coming down. Obviously, I would prefer the debt to come down as fast as possible. But, by stating it this way I am emphasizing that what I am most concerned with are the first two steps: stop the bleeding and stay current.
For more on testing with an agile process like Scrum, pick up a copy of Succeeding with Agile.


From http://blog.mountaingoatsoftware.com/reduce-manual-test-techcnical-debt

Are you a good Scrum master ?

crum master is a servants leader .. We say this all the time.. So Scrum masters .. how good you rate yourself as a leader is scrum project. check out this matrix introduced by Bob Hartman (Agile Bob)

1. Listening – actively listening to what others are saying
2. Empathy – feeling the pain and thrills of others
3. Healing – helping others after they have been hurt
4. Awareness – understanding the big picture
5. Persuasion – persuading others to do what is right
6. Conceptualization – helping the team understand
7. Foresight – seeing problems before they arise
8. Stewardship – helping the team use resources most effectively
9. Commitment to growth of others – helping others improve
10. Building community – helping the team become more than a
group of individuals


From http://projectized.blogspot.com/2009/10/are-you-good-scrum-master.html

Scrum doesn’t do anything

Brilliant post!


“Doing Scrum” is as meaningless (and impossible) as creating an instance of an abstract class.  Scrum is a framework for surfacing organizational dysfunction.  It is not a process and it is not prescriptive.  The core framework of Scrum, as described (e.g.) here and here does not actually do anything.  It is, in a sense a contract we put in place between those seeking value and those building it.  But a contract doesn’t produce anything.  An interface is passive.  We need an implementation.
Scrum begins to work when people understand it well enough to create a concrete implementation, to emerge a process that is their own.  Understanding and respecting the Scrum framework and the set of rules allows you to become aligned with others, to have a common set of values and principles from which to operate.
Scrum itself can be thought of as similar to a set of game rules.  Think chess, think soccer.  The rules are easy to learn, and knowing them means you can play the game with others.  The rules are the ties that bind us together.  But just knowing the rules means nothing in terms of deriving pleasure from the game.  You need to play, to be involved.  It is doing, not knowing that brings about results.  To play well you need to develop strategy, and in team games you need to develop relationships, and trustful interactions.
In any game, once you start breaking the rules everything falls apart, and no one will want to play with you.  It is the same with Scrum.
So respecting the contract, the rules, or in software parlance, respecting the interface, allows you to create a process that suits your context — and your context is many things… people, industry, business, market place, product, location, language, physical environment, culture, people.  It starts and ends with people.  Scrum doesn’t actually do anything, people do things.  The Scrum process will emerge through the interaction of the people, and it will be different for each organization or team.  And this is where people trip up; too many think that creating their own process starts with breaking the rules.  It doesn’t.  Do that, and you have failed before you begin.
The Scrum process being created must operate within the agreed parameters, must be bounded by the rules.  All methods of the abstract class must be implemented, or the class won’t compile, won’t run.  Try to move your bishop in a straight line in a game of chess, and your opponent will leave the table.  Pick up the soccer ball and throw it and you’ll be red carded.
The framework of Scrum is a powerful mechanism for surfacing organizational and personal dysfunction.  It is that very power that causes people to try to circumnavigate the rules, to take shortcuts.  They don’t want to look.  But not looking doesn’t cause problems to go away or broken things to mend, it just delays the inevitable giant crash.  We don’t call out the value of courage in Scrum for nothing.
Comparing Scrum then to implementation practices such as XP or software craftsmanship makes little sense.  Each of these movements offers excellent tools for implementing a solid Scrum practice, for making the abstract concrete.  Scrum offers a strong framework and a relentless rhythm to shake out the dust of years.
You cannot “do Scrum” but you can certainly embrace it, and the more courageously you do so the stronger will be your emergent process.

From http://agileanarchy.wordpress.com/2009/10/11/scrum-doesnt-do-anything/

The Problem With Planning

Hi, this is Kelly, from Agile Software Development Made Easy!

I think I've been pretty successful in my career. But if I was better at planning, I wouldn't have achieved half the things I've achieved in my career! In fact, I wouldn't even have started some of them...


In reality, there are some things you can plan, and some things you can't. The trouble is, in most organisations we've come to expect a plan. And to meet it whatever happens. And that's just not realistic.
<!--break-->

Doing detailed planning pre-supposes you know where you want to go and aren't going to be influenced too much by what happens in the meantime - or at least not without a substantial amount of re-planning. This, at least in my experience, has a tendency to give project managers tunnel vision at times.

Now don't get me wrong - I'm not suggesting for one moment you embark on a project that doesn't have a clear and robust vision. And I'm not suggesting for a moment you embark on a project where you have no idea how to achieve it and whether it's a reasonable (although hopefully challenging) goal with the available resources. And forming that into an outline plan to provide some markers to aim for is certainly a good idea, but ideally it's a high level roadmap rather than a detailed plan.

Coming from a traditional software development environment, I realise this sounds slightly mad. And I must admit it takes a certain amount of maturity and experience to recognise that you can't really plan in detail up-front if you want to retain any flexibility, as the real requirements, risks, issues, priorities and opportunities all tend to emerge when you start to build and see the software in action.

Most organisations are not be ready to accept such a radical idea - the idea of acknowledging you don't really know what you want - certainly not for sure - and you don't really know what you're going to get for your money, or when. So, as a minimum, a clear vision and outline plan are essential, but be careful to keep them to a high level.

Rather than a detailed plan, I prefer to see a strong vision, a strategy, goals, and a roadmap (high level outline plan). The tactics to achieve this, for example the precise features and all the tasks to deliver them, can vary along the way and are best not articulated up-front. This enables the team to discover the details when they are in a better position to do so, and allows them to change direction rapidly in response to changing circumstances.

This, when you think of it, is the very meaning of agile...

Kelly.


Photo by tanakawho

So, You Want to be a Software Programming Rock Star?

A great Google Tech Talk by Joshua Kerievsky, where he discusses some of the challenges faced by programmers, common gotchas and how Industrial Logic ’s eLearning albums can help you to improve your Programming Skills.

Some of the following topics:

• What are ‘code smells’ i.e. bad design
• How do you improve the design of existing code (java, C++, C#)
• How do you write good unit tests?
• Test Driven Development
• How do you deal effectively with legacy code?
• Design Patterns

ABSTRACT

Presented by Joshua Kerievsky.

Software programming rock stars test-drive their code, refactor mercilessly and deftly apply design patterns.

If youd like to get from musician to rock star status, a good place to start is Industrial Logics eLearning albums. Crafted over the past 4 years, these interactive, multimedia tracks feature challenging labs that rank your level and suggest improvements, engaging videos by experts, stimulating quizzes and an ability to ask questions and receive answers by knowledgeable practitioners.

Join Joshua Kerievsky, founder of Industrial Logic, as he guides you through his company’s state-of-the-art eLearning albums on timeless software design skills.

Agile Project Management – Self-Organisation: The Secret Sauce for Improving your Scrum Team

A ‘must watch’ Google Tech Talk by Jeff Sutherland, one of the founders of Scrum, about the ’secret’ ways to achieve ‘hyper-productivity’ in an Agile Project Mangement environment.

In this seminar, Jeff talks about the following topics:

• Introduction to the ‘Scrum But…’ (!)
• How to monetise improved team performance
• Shock therapy as a strategy for booting up teams.
• The Cosmic Stopping Problem, otherwise known as the choice uncertainty principle.
• Punctuated equilibrium – how software systems evolve

Google Tech Talks
September 4, 2008

ABSTRACT

High performance depends on the self-organizing capability of teams. Understanding how this works and how to avoid destroying self-organization is a challenge. Until you understand complex adaptive systems and how Toyota works it is difficult to improve team velocity.

Jeff will discuss three core topics:

1. Shock therapy as a strategy for booting up teams.
2. The Cosmic Stopping Problem, otherwise known as the choice uncertainty principle.
3. Punctuated equilibrium – how software systems evolve

Take advantage of these concepts and you may find a way to achieve the ultimate potential of a team. This session will be a “Deep Agile” presentation keying off topics presented to engineers at MIT.

Speaker: Jeff Sutherland
Dr. Jeff Sutherland is one of the co-creators of the Scrum software development process. He and Ken Schwaber invented Scrum in 1993. Since then he has worked with many software companies and IT organizations to extend and enhance this process.

The Difference Between Waterfall, Iterative Waterfall, Scrum and Lean Software Development (In Pictures!)

Here’s a VERY simple overview of the main differences between Waterfall Development, Iterative Waterfall Development, Scrum/Agile Development and Lean.

Waterfall Development

‘Waterfall Development’ is another name for the more traditional approach to software development.

It’s called ‘waterfall’ as this type of development is often planned using a Gantt chart – you complete one phase (e.g. planning) before moving on to the next phase (e.g. development).

In Waterfall approaches, you will rarely aim to re-visit a ‘phase’ once it’s completed. As such, you better get whatever you’re doing right the first time!

This approach is highly risky, often more costly and generally less efficient than more Agile approaches.

The main issues with this approach include:

• You don’t realise any value until the end of the project (when you deploy) (See: Self-Funding Projects, a Benefit of Agile Software Development)
• You leave the testing until the end, which means you’re leaving issue discovery until late in the day
• You don’t seek approval from the stakeholders until late in the day – their requirements might have changed
• You’re heavily reliant upon a plan, which you can/will often follow to the detriment of the end result
• You’re heavily reliant upon a project manager driving the way – the power of one

Iterative Waterfall Development

This approach carries less risk than a traditional Waterfall approach but is still far more risky and less efficient than a more Agile approaches.

The focus is on delivering a sprint of work as opposed to a series of valuable/shippable features.

The most commonly occurring issue in this type of scenario (in my experience) is bottle necking.

For example, you deliver loads of code a little bit behind schedule (?) and you leave it until the last minute to test everything. One issue takes longer than expected to resolve, you miss your sprint deadline and you deliver nothing.

Another common symptom of this type of approach is over-commitment.  It’s really difficult to estimate the totaleffort associated with a particular User Story/Feature when approaching delivery in this phased way. 

You’re more or less forced to estimate each phase separately (e.g. estimate development separately to testing in this instance) – this doesn’t work as the phases are not separate, they’re totally intertwined.

For example, if you find an issue with the test, you must return to development. The whole team must remain focused on delivering the end goal, not the separate phases.

It’s also worth noting that velocity and burn downs are far less (if at all) useful in this type of environment – you don’t benefit from early-warning-signs as you don’t find out whether you’re on track until the end of the sprint.

Scrum Development

This approach carries far less risk than Waterfall approaches.

We focus on delivering fully-tested, independent, valuable, small features. As such, we diversify our risk – if one feature goes wrong, it should not impact another feature.

With that said, we still plan our work in iterations and we will still release at the end of each iteration.

Lean Development

Lean is very similar to Scrum in the sense that we focus on features as opposed to groups of features – however Lean takes this one step further again.

In Lean Development, you select, plan develop, test and deploy one feature (in its simplest form) before you select, plan, develop, test and deploy the next feature. By doing this, you further isolate risk to a feature-level.

In these environments, you aim to eliminate ‘waste’ wherever possible – you therefore do nothing until you know it’s necessary or relevant.

What does ‘Done’ mean in Agile Software Development?

In Agile Software Development environments, we aim to deliver ‘[potentially] shippable code’ at the end of each iteration.

In actual fact, we often settle for delivering a chunk of value at the end of each iteration.  This ‘value’ may or may not be directly attached to a piece of shippable code. 

We also aim to close each iteration with no leftovers, no dependencies – everything must be ‘done’.

I recently watched a Google Tech Talk by Jeff Sutherland where he discusses ‘Done’ (Scrum Tuning: Lessons Learned at Google). 

Jeff explained that ‘Done’ at Patient Keeper, his company, is a piece of code live to the public having received no complaints within an hour of release.  

This got me thinking.

• So, what is ’Done’?… 
• Does ‘Done’ HAVE to be ‘live with no complaints within an hour of release’?…
• Does ‘Done’ HAVE to be potentially shippable code?
• What does ‘potentially shippable’ mean?
• Does ‘Done’ HAVE to relate to the delivery of code?
• Can ‘Done’ change one a case by case basis? …

In traditional, Waterfall, environments, we follow a series of consecutive steps running between project inception and completion – we understand that we are ‘done’ when all of the steps are complete, the product is released, we disassemble the project team etc.  This is a relatively simple concept to get your head around.

In an Agile environment, however,  we follow these steps each iteration… in fact, we probably follow these steps a number of times per day.

Of course we’re interested in being ‘done’ with the project, but we’re more interested in being ‘done’ with each task, each story and ultimately each deliverable that will in turn deliver value.

So, now we need to define ‘value’! Is value *only* delivered by shipped code? Probably not.

For example, the objective of a Spike is to get a clear idea on where to go next.  ‘Done’ in this situation might be a working prototype that might end up being released – if you’re lucky.

On the other hand, the task(s) could be to deliver a series of findings that inform a decision - ‘Done’ might be a firm decision one way or another e.g. completion of the Planning and Analysis stages.. (see inset image)

As mentioned above, you may decide not to release at the end of each iteration. You may schedule releases around Minimum Marketable Features or Epics that span multiple sprints. In these cases ‘Done’ may relate to the delivery of ‘potentially shippable’ code, which has been fully-tested, acceptance tested and performance optimised (as much as possible).

So, it becomes clear that the definition of ‘Done’ may indeed neeed to vary on a case by case basis.

With that said, regardless of what your definition of ‘Done’ is, the definition must be understood by everyone involved.

From http://agile101.net/2009/09/04/what-does-done-mean-in-agile-software-development

Scaling Scrum & Distributed Teams – Scrum Tuning: Lessons Learned at Google

A fantastic Google Tech Talk by Jeff Sutherland, one of the founders of Scrum, where he introduces Scrum, Agile and offers a lot of insight and guidance on how to scale Scrume.g. the Meta Scrum.

Google Tech Talks
December 7, 2006

ABSTRACT

Adwords introduced a Scrum implementation at Google in small steps with remarkable success. As presented at the Agile 2006 conference this exemplifies a great way to start up Scrum teams. The inventor and Co-Creator of Scrum will use this approach in building the Google Scrum implementation to describe some of the subtle aspects of Scrum along with suggested next steps that can help in distributing and scaling Scrum in a “Googly way”. Credits: Speaker:Jeff Sutherland

Jeff discusses the following points:

• History of Scrum
• Introduction to the Agile Principles
• Overview of the ‘Toyota way’
• Fujio Cho (Chairman of the Board of Toyota) interview
• Overview of the ‘Google Way’
• Distributed Teams and Google Adwords
• Scaling Organisational Social Structure (Organic, Autocracy, Leadership, Bureaucracy)
• Scrum is ‘linearly scalable’ – double the team size, double the output
• Introduction to the Product Owner
• Introduction to the ‘Meta Scrum’ – (Chief Product Owner, Stakeholders, CEO etc)
• The ‘Meta Scrum’ at Patient Keeper
• Scaling Scrum
• The Scrum Framework
• What does ‘Done’ mean at your company?
• Introduction to Scrum Documentation, Meetings and Roles
• Introduction to the Scrum Master
• Introduction to the Release Burndown Chart
• Introduction to the Scrum of Scrums
• Work In Progress is bad!
• Introduction to XP ‘Spikes’ (timeboxed R&D)
• Fitting your Testing into your sprint!
• Nokia Scrum Assessment
• Changing the scope of ‘Done’
• Introducing the Sprint Backlog
• The Daily Scrum Taskboard
• The Wisdom of Lao Tse
• Hyperproductivity in Scaling Scrums
• Isolated Scrums, Distributed Scrums and Totally Integrated Scrums
• Case study on scaling scrum – distributed teams
• Project Reporting (Scope Additions, Burn Down, Cumulative tasks in QA, Work Closed Burn Up)
• Multi-threading and implementing a ‘Type C’ Scrum – when the same team is working on multiple projects

Lean is more than a set of tools

I hear a lot of people talking about Lean as if it were just a set of tools.  I also hear a lot of people saying it doesn't make any sense to try to contrast Scrum and Lean.   If you believe the first, you will likely believe the second. This blog is an attempt to show how Lean has a set of tools, but isn't just a set of tools.  By tools, in our case, I mean the practices with which to solve problems we encounter.

Before I talk about Lean, however, let me talk about real tools - since that is the analogy I am most often given.  Let's say you are a carpenter and have a tool box.  It doesn't make sense to talk about one tool being better than another.  The question is, which tool works best in this situation.  As a carpenter, I can learn how to use the tools in different situations.  Let's say I mostly make furniture.  Then I can learn how to build dressers, how to build cabinets, how to build tables, ...  I can learn which tools to use in which certain situations.  There are quite a few number of these, but I can become fairly proficient at it in my domain. 

What, however, happens if I become a journeyman? Now, I am in a new situation.  I have experience using tools, however, so I am not lost.  I try the tools in the new situations.  I see what I did, contrast it to what I wanted, and adjust my methods accordingly. This is the "inspect and adapt" approach many agilists are so fond of.  There is some waste in the process, but results will eventually be achieved.

Now, what happens if one knows more than how the tools work, but also understands why they work.  For example, a basic carpenter knows that nails work in certain situations better than screws.  However, many carpenters don't actually know the mechanical laws on which nails hold together two boards vs the mechanics of how screws do it.   While it might be generally true that screws will provide more strength at a higher cost of implementation - it is only generally true.  Bigger nails in some situations will work better than small screws.  But too big of a nail and you might split the wood.   A carpenter will learn from experience what to use.  And in a new situation will make mistakes and correct. But if he knew the principles behind the mechanics of screws and nails, he might be able to make better decisions, more quickly, in a new situation.

In the physical world, this extra knowledge is often held in the role of an architect.  Someone who understands the forces of construction better and will figure out what is needed - letting those more proficient in practices, but less proficient in principles do the work.  In my mind this illuminates the distinction between knowledge that assists operations (practices the carpenter uses) and knowledge that assists decisions (principles being used by the architect).

This, of course, requires the belief that there is a set of laws here.  This is one of the fundamental differences in different "camps", so to speak, in the Agile community.  Many agilists don't believe there is such a set, and that what we do is more art than science.  We are in an empirical situation, to them, and we can only inspect and adapt our way through it.  On the other hand, many other agilists do believe there is such a set.  In my mind, this is one of the foundational beliefs of Lean-thinking - that there is a set of rules out there.  Plan-Do-Check-Act is based on the notion that we can plan our work based on our current understanding of how things work.  We check our results against this plan.  Part of our acting is then to redefine our understanding of the way things work.

So Lean provides practices to our Agile toolbox. Things like limit work-in-process (WIP) to capacity, don't do things until they are ready to be used (Just-In-Time), do value stream mapping, ...  This is the Lean toolset.  If one believes Lean is just this set, then picking the right tools to use is the best approach you can do.  Use Scrum practices (daily standups, sprint planning, ...) where they apply and use Lean practices when they apply.

If you understand the Lean principles underneath the Lean practices, however, much more is available to you.  First of all, all practices in software development are most likely better understood with the Lean principles. Using Lean principles, one can see how to better apply Scrum practices.  So Lean becomes a combination of Lean practices, which apply only within certain contexts, and the principles on which they are based - which can provide insights into any practice in any context.

Unfortunately, this approach does not match most people's learning or working style.  People like concrete practices to use.  One of the value of coaches is that they can relate to people in very concrete terms.  Very experienced coaches may not understand the principles on which their work is accomplished, but they have so much experience they can intuit good results.  People working with them will become more proficient.  At this level, both coach and disciple will view what is happening as following practices within particular contexts.

My view is that Lean is several layers deep.  The most visible layer is its set of practices:

• 
  
  limit work to capacity
• 
  
  use value stream mapping
• 
  
  have the people close to the work make the decisions on how to do the work
• 
  
  avoid large batches
• 
  
  continuously re-plan
• 
  
  avoid delays when possible
• 
  
  focus on getting value delivered to customers quickly more than focusing on having people always be productive

and there are many more.  But this is not Lean. This is merely a set of practices based on Lean-Thinking - or Lean Science as I sometimes call it.

Some of the Lean principles on which these practices are based are:

• delays between when an error occurs and when it is detected causes waste
• removing such delays can both achieve higher quality and lower cost
• quick feedback results in lower waste
• deferring commitments can reduce waste
• optimizing a segment of the value stream often results in increasing costs, increasing time to delivery and lowering quality

and again, this is only a partial list.

The opportunity is for people to use Lean practices while getting deeper insights into Lean principles.  This will allow them to adjust their practices when they find themselves in different situations than they have found themselves previously.  In the world of software development, we are all journeymen.  That is, we are always working on new things than the things we worked on before.  Experience is invaluable here.  But an understanding of why we have achieved the results we have can be just as valuable.

If one is interested in learning more about these concepts, I highly recommend looking at our upcoming book Lean-Agile Software Development: Achieving Enterprise Agility.  Several chapters are currently online.

Alan Shalloway

---

From http://www.netobjectives.com/blogs/Lean-Is-Not-Just-A-Set-Of-Tools

How to think like a Scrummy

from http://www.presentationzen.com/presentationzen/2009/08/10-tips-on-how-to-think-like-a-designer.html

Most people do not really think about design and designers, let alone think of themselves as designers. But what, if anything, can regular people — teachers, students, business people of all types — learn from designers and from thinking like a designer? And what of more specialized professions? Can medical doctors, scientists, researchers, and engineers, and other specialists in technical fields benefit in anyway by learning how a graphic designer or interaction designer thinks? Is there something designers, either through their training or experience, know that we don't? I believe there is.

Below are 10 things (plus a bonus tip) that I have learned over the years from designers, things that designers do or know that the rest of us can benefit from. When I speak around the world I often put up a slide that asks people to make as many sentences as they can beginning with the word "Designers...." The goal of this activity is to get people thinking about thinking about design, something most of us never do (it also gets people in the audience talking, loosening up a bit; always a good thing). The sentences they generate range from "Designers wear black" to "Designers use creativity and analysis to solve problems" to "Designers make things beautiful," and so on. (Click on the "Think like a designer" slide to see the 11 tips in slide format on Slideshare.net — feel free to use them if you like.)

These ten are broad and even a bit philosophical. Regardless of your profession, I hope there is an item or two that you can apply to your own work.

(1) Embrace constraints. Constraints and limitations are wonderful allies and lead to enhanced creativity and ingenious solutions that without constrains never would have been discovered or created. In the words of T.S. Eliot, "Given total freedom the work is likely to sprawl." There's no point complaining about constraints such as time, money, tools, etc. Your problem is what it is. How can you solve it given the resources and time that you have?

(2) Practice restraint. Any fool can be complicated and add more, it takes discipline of mind and strength of will to make the hard choices about what to include and what to exclude. The genius is often in what you omit or leave on the editing room floor.

(3) Adopt the beginner's mind. As the old saying goes, in the expert's mind there are few possibilities, but for one with the beginner's mind, the world is wide open. Designers understand the need to take risks, especially during early explorations of the problem. They are not afraid to break with convention. Good designers are open minded and comfortable with ambiguity early on in the process, this is how discoveries are made.

(4) Check your ego at the door. This is not about you, it's about them (your audience, customer, patient, student, etc.). Look at the problem from their point of view -- put yourself in their shoes. This is not easy, it takes great amounts of empathy. Get in touch with your empathetic side. Empathy — an under valued "soft skill," can be a great differentiator and is key for truly understanding a problem.

(5) Focus on the experience of the design. It's not the thing, it's theexperience of the thing. This is related to #4 above: Put yourself in their shoes. How do people interact with your solution? Remember that much of design has an emotional component, sometimes this is even the largest component (though users may be unaware of this). Do not neglect the emotional aspect of your solutions.

(6) Become a master storyteller. Often it's not only the design — i.e., the solution to a problem — that is important, but the story of it. This is related to #5 above. What's the meaning of the solution? Practice illustrating the significance of solutions both verbally and visually. Start with the general, zoom in to the detail, pull out again to remind us of the theme or key concept, then zoom back in to illuminate more of the detail.

(7) Think communication not decoration. Design — even graphic design — is not about beautification. Design is not just about aesthetics, though aesthetics are important. More than anything, design is about solving problems or making the current situation a little better than before. Design is not art, though there is art in design.

(8) Obsess about ideas not tools. Tools are important and necessary, but they come and go as better tools come along. Obsess instead about ideas. Though most tools are ephemeral, some of your best tools are a simple pencil and sketch pad. These are often the most useful — especially in the early stages of thinking — because they are the most direct. Good advice is to go analog in the beginning with the simplest tools possible.

(9) Clarify your intention. Design is about choices and intentions, it is not accidental. Design is about process. The end user will usually not notice "the design of it." It may seem like it just works, assuming they think about it at all, but this ease-of-use (or ease-of-understanding) is not by accident, it's a result of your careful choices and decisions.

(10) Sharpen your vision & curiosity and learn from the lessons around you. Good designers are skilled at noticing and observing. They are able to see both the big picture and the details of the world around them. Humans are natural pattern seekers; be mindful of this skill in yourself and in others. Design is a "whole brain" process. You are creative, practical, rational, analytic, empathetic, and passionate. Foster these aptitudes.

(11) Learn all the "rules" and know when and why to break them. Over the centuries, those who came before us have established useful and necessary guidelines — these are often called rules or laws and it's important to know them. Yet, unlike other kinds of laws, it may be acceptable to break them at times so long as you know why. Basic graphic design principles and rules are important and useful to know, yet most professionals today have a hole in their education when it comes to the fundamentals of graphic design. I'll try to do my little bit withthe next book to raise the design mindfulness and vocabulary of professionals who do not make a living in design per se, but who have a desire to get better.

This is not an exhaustive list (in fact, I started with about 25 items); there are many other things designers can teach us (and not only graphic designers as well). What is missing from this list? What would you add? Love to hear your ideas.

Link
Checkout 16 Innovation Principles over at Metacool, Diego Rodriguez cool website (look on the right bar — good stuff here).

The role of the business analyst in Scrum

Lisez l'article complet ici.

Agile Epic Board – Epic Card Template

http://agile101.net/2009/08/20/agile-epic-board-epic-card-template/

Advantages of Agile Software Development for Testers

Advantages of Agile Software Development for Testers: "This is a guest blog post from Ray Claridge, who writes a really interesting blog about agile testing caled Tester Troubles.

Over to Ray...

Moving into agile software development can be a daunting experience for any tester, and crawling the Internet for crumbs of comfort does little to ease the anxiety.

I remember how I felt on my first day, going into a mammoth planning meeting and participating in a sizing session with what appeared to be poker cards. When asked why I'd held up a 5, I really didn't know what to say. Talk about a fish out of water!

Like most testers, I gained experience and qualifications over many years whilst practicing the V-Model approach to development. I'm not saying it was easy, but it was pretty straight-forward. Give me a spec, I'll review it, create a test plan, devise tests against it and months later finally test against it. Whereas in agile, there's no big spec, the software functionality evolves during development and testing is required before it's finished!

However, once I got my head around the changes I soon realised the advantages of working in an agile environment:

• Agile re-ignited my passion for testing.
• I spent less time complaining about being the last to know when there's a requirement change.
• For the first time I felt like a valued member of the team.
• Developers looked upon me as one of their own, instead of the nasty tester in the corner.
• I was being engaged and used for my creativity, skill and critical thinking.
• Tried and tested test techniques still applied.
• User stories are just like bite size specifications, only easier to digest.
• The business were more engaged with the process.
• I was more engaged with the business.
• The business was happier with the process.
• The business were ending up with software that meets their needs at that moment in time, not the software they thought they wanted 6 months ago.
• I was helping to shape the requirements.
• I lost a huge amount of negativity and became more positive, motivated and accommodating tester.
• I spent far less time sitting around waiting for code to be delivered.
• I no longer waited days, sometimes weeks for defects to be fixed.
• I felt I was adding real value.

Now I know there are some testers and managers out there who will disagree with agile and will never accept it as a development process. Some have even considered a career change to avoid it. I'm not saying agile is perfect and like all methodologies it's not without it's faults, but for me it's been a breath of fresh air.

My advice to any tester about to embark into the world of agile would be: keep an open mind, be flexible, accept the tester's role IS changing and remember, agile is here to stay. Don't fight it, embrace it!

Ray.

Ray Claridge is an experienced tester with ISEB qualifications and experience in both agile and waterfall environments, and author of the popular blog, Tester Troubles.

Agile Estimation and the Cone of Uncertainty

http://agile101.net/2009/08/18/agile-estimation-and-the-cone-of-uncertainty/

Scrum Checklist - version 2.0

http://www.crisp.se/scrum/checklist/scrum-checklist.pdf