Even after years of Subversion, this is one of the most common questions asked by agile teams. This is also a topic of religious discussion. Proposed here is a time and tested simple project structure that you can use for any Java, .NET project. If you are using Grails or Rails, the tool itself provides a similar code structure.

$\{CompanyName}
\{ProductName}
\trunk
\docs
\lib
\build
\src
\. . . { project folders }
\database
\test
\. . . { project folders }
\tools
\. . . { project folders }
\target
\releases
\tools

{ CompanyName } –This is your root name of your company, brand of product.
{ProductName}

trunk– This is the root branch, where new feature development will occur.This is where all developers will check in on a daily basis

trunk/src – All source goes here.

trunk/lib– This folder contains binaries, jar files referenced in test projects, as well as support applications (
junit.jar, nunit.framework.dll, nant, ant.jar)

trunk/build — This folder contains support scripts necessary to build the main branch.Also here is where you could store your build scripts for continuous integration.

trunk/docs — This is where any necessary docs per definition of done will go.

trunk]database — This folder contains all versioned SQL scripts needed to build the various databases.

trunk/test — This folder contains all test projects will go. You may want to keep unit tests here or with the source tree and then just exclude it from the release build.

trunk/tools — This folder contains all projects that are support tools, such as command line utilities.

trunk/target — Source from all the internal projects in source should compile to a common target folder.

/branches — This folder contains release branches, which will be branched from trunk for every release.

/tools — This folder contains any utility applications and scripts.

Well, bully for Tom – after years of thrusting structured approaches to developing software down our throats, in a recent article of his he’s now telling us to give up the details and go for the big idea behind the software. As if anyone has ever had time to do one or the other…

Successful software projects can be put down to a lot of factors, but the biggest one of them is luck – luck in having a good team, who know what they are doing and where they are going, and have fun getting there; luck in having management and the customer as part of that team and not as a hinderance; luck in not being underfunded, having enough time to do the job properly and being allowed to keep the team intact; luck in having a good idea in the first place. If you’ve got that much luck, you’re probably onto a good thing. Don’t you love that word “luck”? It could almost pass for the past tense of “lick.”

But he did mention one point which I liked, and that was the fact that development is experimental. This has given me an idea for a new movement in software development. I don’t think that “experimental” is quite the right word for it, I would rather call it a speculative endeavour in the true sense of the word. It’s got all the advantages you need to start up a new cult with – the name: Speculative Software Development; it’s appropriately vague and non-informative; has a multitude of meanings which the erstwhile developer can interpret for his/her own needs; has the taste of money making so that the management are happy; has the necessary philosophical depth so that the architects can bathe in the glow of its self-importance. Most importantly SSD has a short acronym with at least two S’s in it, so that project managers and team leaders can think that they are heading a crack, elite, alpha plus military task force, which makes up for not being able to play soldiers at home.

On the slightly more serious side, if people are looking for methods, or simply ways of working in development (and I’m not talking about SCRUM – that’s just a methodological framework – it’s what goes into it that’s important), then maybe they should start drawing analogies with how daily papers or magazines are produced, instead of thinking that development has anything to do with the building industry.

Why bring in such a metaphor? Because the techniques and work practices made available can deal with one of the factors which in previous methodologies has been largely ignored, namely that software development is a thoroughly creative activity. Now, you will often find developers moaning that their creativity is capped by this or that constraint, or managers who say that the last thing they want is a creative developer, but this simply shows a lack of understanding of what it means to work in a creative industry. I would argue that creative processes are as rigorous as most engineering processes, if not more so, (okay, I’m not counting going to the moon), but are always organised around individual and collective creative input at all levels, and allow the harnessing of inductive thought, as opposed to the simpler structuring of deductive thought.

Anyway, to cut a long story short, I think that Tom is probably right in signalling the death of software engineering, in that it has began to stifle the motivations behind software development, but people need to start looking for new metaphors and practices for organising their work which take into account the creative and speculative nature of development.

And now a toast to engineering. Long live software engineering!

Please take  minute to go through this slide deck and share them with friends.Appreciate the help .Our best wishes for your quest in Agility.

This is a quick cheat sheet, that captures agenda for some of the core meetings. Some of these are our ideas but mostly these are all widely accepted by all in the Agile Industry.Print this and use it for your benefit.

Download here

We are often asked about books for agile teams. Here is a great starter list for teams practicing agile software development.
Agile Bookshelf

If you have multiple scrum masters in your organization, it will be good exercise to come up with a charter for your group.

Here is an example of one such statement

“ As scrum masters of , we are servant masters enabling teams to deliver business value in the software we develop, protecting teams from external interferences, resolving impediments that teams have and coach teams in better ways of achieving software agility”

Our core values are

- Passive listening
- Respect
- Courage to speak up
- Be compassionate and help team member be better at what they do.
- Always find new ways to improve.
- Remove impediments that team members have.

I recently read this article written by Margaret Wheatley and wanted to share it, as it really got me started thinking.

The questions is this: As old systems and methods fail, how can we develop new ways and succeed in sharing them with others and thereby work to change the future?

The funny thing is that when I read this it instantly got me thinking about music. The whole sort of process that she describes reminds me of the coming of a new music genre (looking back at some of those I have witnessesed like Metal or Electronic). At first there are very few pioneers doing their thing, being looked down upon or simply not understood, but at some point they connect and find likeminded people and together they develop this new style. At some point their music get’s recognised and get’s more followers and this is when larger amounts of people starts to connect to it, enjoy and embrace it.

Read the article here: Supporting pionering leaders

ike Cohn talks a  lot about this in his book Agile Estimation and Planning. You can use any measure to size stories.

Teams use different sizing techniques

T Shirt Sizing

X Small, Small , Medium , Large , Xtra Large

or

Coffee Sizing

Small, Tall, Grande

You can pick any sizing technique. Make up one if needed.

This is mainly done as we as humans and as managers are better at abstract terms. If we use hours as a way to size stories,then the managers in the room have questions, teams dont immediately feel comfortable with hours.

Sizing keeps the planning meeting at a fast pace.

A general measure you can use  for T Shirt sizing is how many days it take to complete a story

Small story –  1-3 days

Medium – 3- 5 days

Large – 5 – 7 days

X Large > 10 days

In order to convert a story size to a number you can use either factorial, Fibonacci or Squares.

Sizing Techniques

If in  a sprint your team does two small stories and two medium  then your velocity is 9 * 2 + 4 * 2 = 26 ( if you are following the squares techique). Square is simple and works quite well.

The word potentially shippable does not mean that you ship to production every Sprint in Scrum

You can have stories that span multiple sprints, that may not make it to production. This may be part of a larger EPIC story. The goal is to work on it every sprint. We have seen many instances where the product owner decided to ship the story half way through that process, as they see see that what is developed so far is not complete, but is good enough to ship.

You can use what is called as Spike. This is not a Scrum specific word. If your product owners asks you to build a robot and you are a software developer who has never done that , then it is obvious that you will not be comfortable giving a sizing or estimate on that story. Instead you can write a story called a Spike. This is a real story that your team will work on .

The intent of the story is to understand the actual story better Example: Investigate a build vs buy option Write some code that gives you enough confidence to understand the complexity involved in building a robot. Compare options example you may write some code to compare different OR mapping layers like Stored procedure, Hibernate , Object databases etc In the end estimation is always a guess. You can never be perfect You will get better at it as your team works together on that domain for a a while.

This is done by using your capacity. Lets use an example to illustrate this.

Say you are a member of a scrum team where there are  8 members , and you are following a two week Sprint.

So initial estimate of every team members capacity is  80 hours i.e. two weeks.

Some of the best scrum teams in the world work at 70 – 75 percent capacity. What that means is in the eighty hours they are at work, they would have to attend to company emails, go to meetings that are required at a company level, take lunch breaks, go on sales call etc. If you have another project then instead of 70 percent you only account yourself at 60 percent capacity. When many teams start with Scrum, we recommend them to start at 50 percent capacity. The other 50 percent accounts for day to day activities in your company.

Say your team is doing 50 percent capacity. That means each person in a two week sprint is only accounted for 40 hours. Out of which if you have a vacation day 8 hours, you take off 4 hours (The rest 4 hours you can account to the fifty percent)

Take a hypothetical example for a two week Sprint of a team at 50 percent capacity ( as this is a fairly new team to Scrum)

This team is made of Charles, Mike, Annie, Bob and Ray . Plus a scrum master. We don’t count the Scrum master’s hours in Scrum, unless they are pulling tasks off the task board .

Mike is there for both the weeks =  40

Charles has one day he is not there = 36

Annie is a part timer and she only works three days a week. So her capacity is 24 hours

Bob = 40

Ray = 40

Team Actual Capacity = 40 + 36 + 24 + 40 + 40 = 180 hours.

If the team worked all the two weeks at 100 percent capacity the would have a capacity of 8 hours a day * 10 days in a sprint * 5 team members = 450 hours.

See the difference of what is used in Scrum  and the theoretical 450 that now one can work. That is what provides the cushion and allows for the team to provide a sustainable pace in every Sprint.

Agile FAQ is a service of Net Present Value LLC and is based out of Seattle WA and was founded by Vibhu Srinivasan who is a technologist, agile coach and architect with more than fifteen years of experience in developing large scale systems in Java, C# and Ruby among others.

He has an MBA in Strategic Management from UW Madison and an electrical engineering degree from Karnatak University, India. He is a certified Scrum Master and a Certified scrum practitioner. Prior to this Vibhu was working at Solutions IQ in Seattle where he had various roles including the role of an agile coach and Chief Architect for a large scale online gaming services initiative.

Managers , take it easy. In many organizations there is an urgency to measure, look at numbers as they move to scrum within the first two sprints. As a general guideline, do not take too much notice of the statistics for four or five sprints.

Teams take a while to form and norm. They also make a lot of mistakes and tend to work a lot harder in the beginning.  Remember the Agile priciple

Simplicity–the art of maximizing the amount
of work not done–is essential

Teams take a while to master this. Once they have this and resoved team forming, norming, that would be a good time to start comparing them with others.

This question comes up a lot in new scrum teams. The adjustment from a couple of months to two weeks is very tough indeed. Generally speaking do not keep changing the sprint length. One Sprint two weeks, the next three weeks etc.

One of the main tenets of Scrum is “Sustainable pace”. Scrum teaams are able to get to this sustainable pace as they get really good at delivering something in a short span of time ie, 2 or three weeks.

Velocity cannot be precicted well if the Sprint length changes. If you think changing 2 to three weeks is going to help you, you are mistaken. The team will only end up signing of for more work than they normally would. Hence the problem has really not gone away.

In agile development there is no right or wrong. Both Use cases and user stories are offshoots of agile methodologies. User stories have a XP and Scrum backgroung and
use cases dont.

Use cases tend to be a written level contract ( sometimes ) too detailed, sometimes not. There are typically few main sections to a use case. A use case Summary, actors, main scenario, alternate scenarios

There is no one to one mapping of a use case to a user story. Summary is like a story defintion. A use case can break into many small stories.

The main scenario in itself is a story with the actual line items in a main scenario becoming the acceptance criteria. The alternate scenarios become either thier own stories or in some cases simply acceptance criteria.

Both use cases and user stories are as good as the effort put in to write them. Both can turn fairly quickly to a rather mundane and useless document.

Here is an example of a use case broken into stories and acceptance criteria.

USE CASE FORMAT

Use Case Number -1

Actor – Bank customer
Summary - Customer withdraws dollars from his / her bank account.

Main Scenario

1. Customer inserts debit card into an ATM machine
2. ATM machine asks for a four digit pin
3. Customer enters the pin
4. ATM machine verifies the pin and it is valid
5. Customer enters the amount
6. Since there is enough bank balance, ATM dispenses the amount and debits the account.
7. ATM gives the card back to the customer
8. Use case ends.

Alternate scenario

4a) Four digit pin is invalid, ATM machine gives an error and asks the user to retry.
6a) There is not enough balance is the account. ATM machine gives a corresponding message

USER STORY FORMAT

As a customer i want to withdraw some dollars from the shop so that I can buy things i like.

Acceptance Criteria.

1) The customer should be able to enter a pin number. IF the pin number is vali the system should prompt the user for a dollar amount to withdraw.If the pin numer is invalid or there is not enough balance the sytem should show a error message.
2) If there is enough balance the system should dispense the cash and debit the account.

As noticed in the example a user story is converstional and conveys the same thing a use case does. It is a small card , with a conversation that is the acceptance criteia.

In case you need to use use cases use the use case as a start and break them down to stories. If done well, stories should be enough detail for the team to develop the system.

This slide deck from Crisp is a great list to some smells you should watch for when implementing agile practices.

If the team is really not empowered to get the job done, that will bring the system down. You know that the team is not being empowered when each team member does not take responsibility or stays shy of taking decisions. If they always look up to the scrum master or dev lead. If a chief architect walks in a spoils thier plan and no one in the team is empowered to speak back. Telling teams and letting them know that thier destiny ( by which i mean ), how they want to work in the project is completely up to them. Team should get a lot of help in the beginning from experienced coaches. This saves a lot of time wasted later.

TEAMS MAKE OR BREAK AGILE COMPANIES

“Secrets of Agile Teamwork” by Esther Derby and Diana Larsen.

Leadership Role Responsibility of Role

1. Instructor Answers Questions and Supplies Data
2. Follower Provides Support and Encouragement
3. Coordinator Links and Integrates Data
4. Peacemaker Works for Harmony and Compromise
5. Gatekeeper Maintains Working Agreements and Discipline
6. Monitor Makes sure relationships are working
7. Pioneer Asks questions and Seeks Data
8. Influencer Initiates working agreements and team culture
9. Commentator Explains and Analyzes Data
10. Promoter Helps and Encourages Quiet Members
11. Critic Evaluates and Analyzes Relevant Data
12. Reviewer Periodically Checks and Corrects
13. Devil’s Advocate Deliberately looks for alternative and oppositional views

I posted from time-to-time on what I’ve called “sticking points” – how things that you had to do (e.g., practices, processes) to get from Level 1 Business-IT Maturity to Level 2 could trap you in Level 2 if you did not modify them, or in some cases, dispense with them entirely!  It’s not that they are bad practices – quite the contrary – they are essential to maturing beyond Level 1.  But the discontinuities between Level 1 and 2, and between Level 2 and 3 are such that some of the practices will not take you all the way from Level 1 to Level 3.

Anyway, Idris Mootee on one of my favorite blogs, Innovation Playground wrote this post on The Problem With Stage-Gate Process With Experience Innovation.  Although he’s writing about innovation more broadly than for the role of IT, I think the post applies beautifully to the IT world, and is a great example of a sticking point trap.

I’ve seen many cases where a rigorous and well-intended stage-gate process was introduced in a low maturity organization, and helped them increase maturity through a more-disciplined approach to development.  But as they tried to inject a more innovative spin to their discovery and development efforts, were stymied by the stage-gate process.

Please read Idris’s excellent post for a great perspective on why that happens.  Then consider, “Are our development processes ‘innovation friendly’.  Do they allow for the kind of program, rather than project approach, and for experimentation rather than ‘avoid risk at any cost’ mentality?”

This paper focuses on agile productivity. “Individuals and interactions over processes and
tools”, means an average developer is required to interact with others for quite a while
in their day. This is very different from traditional development where face to face
interaction is not that much. Added on to this high interaction in agile teams, is the
interference of meetings, lunch breaks, stand ups (In Scrum), and other technical
challenges like chats and emails.http://agilefaq.files.wordpress.com/2008/03/agileproductivity.pdf

This is a recent email chain that talks about this issue. Very interesting. Thanks to all responders . Posting here for benefit of the larger group.

First Person:

I am a firm believer that the velocity is set by the team (not
management, not Scrum Master) as a measure of how much value they are
able to deliver based on yesterday’s weather and the team’s
capacity/ability at the time.

It’s an easy trap for management to use velocity as a measure of
productivity and assume that if they increase it a little more each
sprint the team will deliver more with the same quality.   That is a
myth.  The team should demonstrate that the velocity is based on the
best we can do given our current capabilities and knowledge we have at
the time.  If there is expectation that they should do more, the
discussion needs to change to impediments that are keeping the team from
delivering more value.  Taking the discussion this way will encourage
the looking for waste and inefficiencies that could be improved or
removed in order for the team to be able to deliver more.

Increasing velocity will not motivate.  If anything, it will cause the
opposite and that the team is being asked to do something they aren’t
able to do on their own and really commit to.  This causes frustration
and breaks down the trust/transparency between management and the team.

Second Person:

The bottom line…You spend something each iteration and that is a function of time, cost, scope and quality.  Fixing time and cost and increasing scope is unreasonable.  Over time, with more maintainable code, better domain knowledge, improved team competencies and better infrastructures will increase velocity.  Most other attempts (except removing people from multiple projects) will usually spend quality. Quality is spent either by reducing product quality or the teams’ quality of life.  Overworking people can have short spikes of productivity (a week or two) but statistics show that people working 12 hours per day are no more productive than 8 hours per day within 3 months.

From a lean perspective, more items will increase waste.  Also, overloading teams causes an overpressure on the teams.  If this were a pipe, the pipe would burst (sending caustic chemicals into the environment with long standing and expensive problems).  Unfortunately, people are much more adaptable than a pipe and so the indicators of emergent problems is harder to recognize until too late.

http://www.scrumalliance.org/articles/14-technical-debt-and-design-death

Third Person:
My suggestion (which has passed no orthodoxy test) is to stay close to
recent experience, and maybe set some reasonable stretch goals IF your
team is building coherence and effectiveness as sprints go by, or are
coming back from a difficulty, or are enthused and excited, or some
situational impediments have been relieved, or they recognize a need to
push some for the sake of the customer relationship. I think you have to
be very sensitive to reading the team psychology – their relationships
with each other, with you, and with the customer. In any case, I think
the team would have to sign up for any stretch goal, rather than having
it imposed by you, or god forbid, by the customer.

Fourth Person:
We have found that signing-up for less lowers the pressure and raises the confidence then the team actually does more than the stretch goal that if attempted always works against you and you deliver less.

Fifth Person:
My experience with stretch goals has been that they have four fundamental flaws:

1) There’s no good way to represent them in Agile planning and tracking tools/data.  If you fully flesh them out with task estimates and plan estimates, then you’ve potentially wasted that planning time (if you don’t get to them), and you’ve distorted your burn-down graph.  In particular, this often leads to quality loss and short-cutting in the first few days of the Sprint as people see that the burndown slope isn’t converging to zero, but don’t realize why.

2) They cause stress and distress to the team.  “Everyone knows” that management half-expects the stretch goals to be met, and yet if we-the-team were confident of meeting them, they wouldn’t be stretch goals, they’d be part of our velocity!

3) They cause bad customer expectations and bad feeling between the development team and the customer.  In every Agile project I’ve worked on, if we gave the customer a stretch goal, the customer inevitably asked at the end of the Sprint, “Well, why didn’t you get the stretch goal done as well?”  The answer, “Because it was a stretch goal”, while entirely accurate and fair, never seemed to satisfy them.

4) Stretch goals are redundant.  We have, at least in theory, a prioritized Product Backlog.  The ScrumMaster and the Product Owner should be collaborating on an ongoing basis to ensure that at least the top 20% of that backlog is current, ordered by priority, well-understood, and ready for inclusion into the next sprint’s Sprint Backlog.  Well, there’s your stretch goals, ready-made and already in priority order.  If you happen to finish a sprint early, at a sustainable pace, and with optimal quality standards (the only time you should ever be looking for a stretch goal at all), you can go directly to your Product Backlog, take the top-most item, and voila, you have a stretch goal.  Negotiating explicit stretch goals with the customer obscures this resource and increases customer confusion about the role of (and importance of maintaining) the product backlog.

For these four reasons, I strongly oppose the use of stretch goals in Agile planning.  Agile already has better solutions to the problems that stretch goals nominally address, and these better solutions are far less likely to cause poor customer communication and team distress.

1. Come prepared to answer three questions and be in time – What did I do yesterday?, What Am I doing today?, Any Impediments?
2. This is not a status report. This is your time to share thoughts with the team, so that they know where you ( or your pair) are and can act accordingly. This is also your time to ask for help and to offer help when asked.
3. Address your team in a loud voice, and don’t report to the project manager
4. All pigs -Stand in a circle around visible indicators like task board, impediment chart and a phone for those dialing in. All Chickens – Stay away and be quiet. After the stand up you can speak too.
5. Keep it short. No standup should go more than 15 minutes.
6. Bring at least one impediment to the stand up.
7. Pick a pairing partner.
8. Make sure the product owner is always there.
9. If this is a distributed team do stand ups separately in the two places and then use another standup to report cross team activities later in the day.
10. Do this first thing in the morning and may be last thing in the day with distributed teams.

This is a standup, so don’t sit.

Customers Measure Success on one of more of these criterias

At a high level:

• Is the project in production?
• Is the product producing revenue?
• How long since development I could get the product to generate revenue?
  • Sometime agile products iterate for a very long time and when finally released end up looking like a waterfall effort.
• How much did i spend in developing a story point or a use case?
• What was planned and how much did I end up spending?
• Is the product in a decent shaped to take it to market?
• How often has the team delivered value?
  • One of the key aspects of agile development is to pick stories that provide value to the business from very early on. It is critical for the success of agile projects that there is a balance of stories from just a feature that enhances a functionality to one that can generate revenue.
• Number of level one of two defects?
• Are all the stake holders satisfied?
• What are the customers saying?
• Have we increased the customer response time?

So you are finally convinced that it is time to develop this “Next Big Thing!”. Question is, what development method should you be looking at?

Well check out some of the key features of Agile Development and decide whether this is more suitable for your team or not. eWeek reports that the Microsoft Visual Studio 2008 (previously dubbed Orcas) development team employed the Agile process successfully in their recent development project. The article also notes that, Microsoft’s “patterns & practices” group has taken Agile to a whole different degree, even designing a workspace dedicated to agile development

So what is this buzzword?

“Agile development helps teams minimize risk by developing software in short iterations. Each iteration results in basically an entire software project: including planning, requirements analysis, design, coding, testing, and documentation.”

As Scott Amber (of IBM Rational) rightfully notes, “…it is more of a cultural issue than a technological issue.” It is also worth noting that Agile development is not a goal, it is a means to becoming more effective.

Some key features of Agile Development:

• close, daily cooperation between business people and developers – (eg. daily 10-minute pow-wows where everybody is brought up to speed with where things are and what needs to be done)
• emphasize face-to-face communication over written documents
• agile teams are located in single open culture offices (usually with no walls) called the “bullpen”
• customer satisfaction by rapid, continuous delivery of useful software
• working software is delivered frequently, at each iteration (within 1 to 4 weeks, not months)
• working software is the principal  measure of progress
• late changes in requirements are welcome
• projects are built around motivated individuals, who should be trusted
• continuous attention to technical excellence and good design
• simplicity
• self-organizing teams
• regular adaptation to changing circumstances

When to choose an adaptive (“agile”) method over a predictive (“plan-driven”) method and vice versa:

Agile home ground:

•  
  • Low criticality
  • Senior developers
  • Requirements change very often
  • Small number of developers
  • Culture that thrives on chaos

Plan-driven home ground:

•  
  • High criticality
  • Junior developers
  • Requirements don’t change too often
  • Large number of developers
  • Culture that demands order

• Check out this video  …”Why does Agile Software Development pay?”