devXero's blog

a blog about agile, development, and automation

Posts Tagged ‘Scrum’

Using Microsoft Surface for poker planning

Posted by Mike Longin on August 27, 2009

I wish I had something to show for this post, but just trust me on the fact that I was shown a really cool tech demo.  EMC Consulting has integrated Microsoft Surface (http://www.microsoft.com/surface/) with poker planning.  I went to take some photos of it today but the demo had already been taken down.  I found this post (http://blogs.conchango.com/pauldawson/archive/2009/02/24/microsoft-surface-where-are-we-at.aspx) that mentions the technology.  If anyone finds a demo or a video please let me know.

Posted in Uncategorized | Tagged: , , , , | Leave a Comment »

Where does the team end and the company begin

Posted by Mike Longin on August 25, 2009

At dinner tonight we were having a small debate about having internal tools teams to support the development team.  On one side of the table was myself.  I belive that teams should use similar tools and methods to allow easy cross compatibility.  Teams should have the leeway to go out and create things they need, but not forget that at the root they work for the same company as any other team.  Having an internal tools team allows the dev teams to remain on their tasks at hand and allow tool based impediments to be off loaded to an internal team whose responsibility it is to maintain the tools.  On the other hand, one of my coworkers was debating that teams should just go do what they need to do to remove the impediments that are in their way.

I believe that we are both right and that there is common middle ground but I do not know where it would be found.  Any takers?

Posted in Uncategorized | Tagged: , , | Leave a Comment »

Is the product owner part of the scrum team???

Posted by Mike Longin on August 7, 2008

I was asked this question last night, and by asked I mean I had a 2 hour discussion in the lobby of the Sheraton about this.

I believe that Agile says no.  The scrum team is the manufacturer and the product owner is the customer.  It is the teams job to produce for the product owner.  But then I stepped back and looked at my team, where our product owner sits in the same room with us and actively helps us do our job better, and thought to myself that she is with out a doubt part of the team.  But at the same time, if she started putting unrealistic expectations on the team, or started asking developers to do things that were not part of the sprint, then I would have to step in and stop that.  With that in mind it seemed that the line between scrum team and product owner was blurry.

But then I came up with what I think is a very interesting analogy on the situation.  Let us pretend for a moment that we work for a company that makes widgets.  Another company uses these widgets when they make there product (lets call it baubles).  Now it seems there is an unlimited demand for baubles, thus this company is constantly trying to obtain widgets for making more baubles.  As the owner of the widget company I want to make as many widgets as possible while still keeping my company whole.  I do not want people leaving because they are overworked, and don’t want people working on waadgets, when its widgets that we are supposed to be manufacturing.  At the same the bauble manufacturer wants as many widgets as possible.

In this scenario both companies share the same strategic goal, make as much money by making as many widgets as possible so that baubles can keep on selling.  Yet at the same time they have different sub goals.  The widget manufacturer wants to protect his company from burning out and the bauble company wants to obtain as many widgets as possible regardless of the cost.  This creates a relationship between the two of them and in effect creates a larger team that encompasses the two of them.

I think the scrum team and product owner have much that same relationship.  The team wants to produce as much as possible yet stay healthy, and the PO wants as much product as possible.  Yet they both want to produce the best software possible which they can sell and make money with.

The PO\Scrum team super team (I am working on a better word) is thus created from the relationship between the two groups.  And while the PO is not part of the traditional scrum team, they are a part of the larger picture.  WIthout a good relationship between the two, they both suffer.  Either because more product can be delivered then is being delivered due to over cautious use of resources, or too much product is being delivered at the expense of the members of the scrum team.  But when the relationship is at its perfect balance, the scrum team is delivering 100% of the product requested by the backlog.

I think the summation of this is that there is a very important team that includes both the traditional scrum team and the product owner.  And it is the relationship in this team that does much to define the effectiveness of both parties.

Mike

Posted in Uncategorized | Tagged: | 3 Comments »

Agile 2008 – Dependency Management in a Large Agile Organization

Posted by Mike Longin on August 7, 2008

Presented by Eric Babinet and Rajani Ramanathan

This presentation was presented by employees of SalesForce.com.  For those that don’t know, salesforce is one of the most prestigious SAAS (software as a service) companies and has implemented Scrum across the board.  This session spoke to the issues of dependencies over multiple teams in an agile enviroment.

A few interesting ideas that they presented and I wanted to get down were (with my own take on it of course):

  1. Key values for success in an Agile enviroment
    • Transparency
    • Feedback
    • Automation 
  2. All teams should be part of the release planning cycle. It shouldn’t be just a top down affair
  3. Teams meet at the beginning of each realease to map out all of the expected dependencys.  Helps to identify where the bottle necks are going to be early on.
  4. Concept Reviews
    • Members from multiple teams meet to discuss implementation and ideas.  Encourages cross team collaboration and knowledge sharing.
  5. Virtual Architecture group
    • Members are composed of members from the individual scrum teams
    • Different members have familiarity with differnt parts of the system
  6. Build Master
    • Babies the build
    • Rotates over multiple people

It is easy to see that the solutions to dependency that SalesForce found were based around communication and cooperation.  And when looking at it froma  distance it is pretty easy to see that this is where the solution would be found.

Posted in Uncategorized | Tagged: , , | Leave a Comment »

No Build…don’t even try brecoming agile

Posted by Mike Longin on August 6, 2008

When it comes to agile, there is one thing that I feel is an absolute requirement for getting this whole process working, a working build.  What do I mean by a working build???  I mean a build that can run multiple times a day, every day.  A build that can be used as part of CI (continuous integration) and as a part of the package process when shipping.

Without a build everything comes to a stand still.  Teams can not verify if there code checkin’s conflict with another teams.  Unit tests can not be run to verify code functionality.  And worst of all, no body really knows if the system is working.

But when it is all running smoothly then it is a thing of beuty.  CI runs multiple times a day to verify all checkin’s not only build properly, but all unit tests are passing as well.  The quality assurance team can test on a true version of the system, not a jerry rigged build that may not have any basis in reality.  And best of all at the end of a sprint, you know that the code you are showing is 100% honest in what wil be given to a customer.

When it comes to going agile…make sure the build goes first.

Posted in Uncategorized | Tagged: , | 2 Comments »

Should a sprint review be only positive???

Posted by Mike Longin on August 6, 2008

This is a question that comes up from time to time on my team.  Should a sprint review only be about the positive.  And if so what do we do about the negative.

I have 2 examples that illustrate my question.

1.  Your team sets out to accomplish 40 points but only accomplishes 36.  Do you spend any part of the sprint review dwelling on those 4 missing points.  If so how do you go about discussing them.  Or do you wait to the retrospective to discuss them.

2.  Your team has accomplished all of the objectives and stories for a sprint, yet is aware that there is more work left to be done.  The product owner for whatever reasons disagrees over the teams assessment and feels it is time to move on.  Is the sprint review the time to bring up this issue since it is one of the few times that the powers that be are all located in the same room.

These are two questions that time and again we are faced with and have yet to find the answers.

Posted in Uncategorized | Tagged: , , | 3 Comments »

Agile 2008 – Trouble with component teams and an alternative with Bas Vodde

Posted by Mike Longin on August 6, 2008

Let me start by saying what a great session this was to attend.  Bas Vodde (http://www.odd-e.com/blog/) is one of the fathers of lean\agile development and listening to him was really a great experience.

The session topic dealt with how large teams (50++) handle scrum.  He actually has a new book coming out that I am looking forward to reading (Scaling Lean & Agile Development).

The first thing discussed was Conway’s Law which I had not heard of.  There is a good summary here (http://en.wikipedia.org/wiki/Conway%27s_Law).  To summarize

  • Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

Meaning that if a team is divided on some generic lines, the system itself will end up with divisions along the same lines.  While I have not heard of this law before I can attest to seeing this kind of division in different products and projects I have seen.

Bas’s main point throughout the talk is that teams need to be broken up as feature teams and not component team.  A component team is a team that owns part of the product.  Examples would be a UI team, or a file management team.  Feature teams are designed to pull tasks off the backlog indiscriminately.  Each team has the ability to change any part of the system due to a combination of diversity on the team and component guardians (which I will explain later).

One of the next points he brought up was that teams that have multiple product owners (under 100 members of the development team) really are just setting themselves up for failure.  The optimal situation is that there is one product owner and one backlog.  And that each feature team can handle any item on the backlog.

For feature teams to work one of the things needed is a good Continuous Integration system.  What this means is that the developers are constantly integrating their working code into the main build, and the system regularly is built to ensure compilation is possible.

Another important part of this is the concept of component guardians.  This is a single person who watches over a component to ensure all modifications to it are compliant with the original intent.  These component guardians can meet regularly with the developers of the system to help the feature teams make use of existing functionality.

I know this was brief but I am going to end this for now.  I am planning come back to this post in the future to examine how my company uses some of these techniques.

Mike

Posted in Uncategorized | Tagged: , , | Leave a Comment »

Agile 2008 – Questioning Agile with Scott Barber

Posted by Mike Longin on August 6, 2008

So my first session today was with Scott Barber(http://www.perftestplus.com/scott_blog.php).  His session was about questioning agile.  Agile itself is constantly evolving and as a practicer it is important that those who are  practicers to keep rethinking what it really means to be agile.

Some of the questions that he asked are:

  • What is agile?
  • Who sez you really are agile?
  • What does it mean to be agile?
  • Do teams make decisions?

The last question I found to be really interesting.  As a team member so often we make decisions for the team and yet when it comes down to it most of the time these need to be approved.  Some of these decisions are simple like when a meeting is scheduled.  But many times they have much more serious repercussions such as determining a build is ready for release.  And really while the team does decide its not up to them in the end since its not the team that usually is financially responsible for that decision.  Thought it made a really good conversation point.

Another good comment he made was (and this isn’t verbatim) “Software developers write software that they would like to use and not necessarily what the customer would want.”  And I found that so obvious yet very profound.  So many times when it comes to some decision we make as a developer we just make it without asking the customer what they might want.

Felt that he definetly opened up some good talking points and wanted to pass them on.

Mike

Posted in Uncategorized | Tagged: , , | Leave a Comment »

Does Agile mean Open???

Posted by Mike Longin on August 6, 2008

One of my feelings about Agile has always been that in reality it is just a way of promoting openness and transparency.  What I mean is that with good agile practices the relationship between the customer and dev-team is entirely open.

As a developer I know exactly what the customer is expecting.  Every 2 weeks (2 week sprint length) the customer gets to see exactly what the developers are working on.  On top of that I can see what they are planning long range.

As a product owner, I get to see what my developers are working on.  I know within 2 weeks what they will be doing for me, and I know that my expectations will be met.

To me that is just being open.  Everyone knows everything.

I would be interested in others thoughts

Mike

Posted in Uncategorized | Tagged: , , | Leave a Comment »