tag:blogger.com,1999:blog-92061086637802206602010-08-19T15:31:07.867-04:00Practical approaches to Agile/Lean Software DevelopmentMaurohttp://www.blogger.com/profile/12233267053232498223noreply@blogger.comBlogger15125tag:blogger.com,1999:blog-9206108663780220660.post-22874615414106831132010-08-07T17:30:00.000-04:002010-08-07T17:30:22.305-04:00

I came across an interesting observation in a book I have been reading lately [1]. Alan Shalloway wrote "imagine having completed a software development project, only at the end to lose all of the source code". Although a scary scenario, it illustrates well that the hard work in a software development project is not the writing of the code itself but figuring out what the software is really

Maurohttp://www.blogger.com/profile/12233267053232498223noreply@blogger.com0tag:blogger.com,1999:blog-9206108663780220660.post-74848027289240747602010-06-29T19:59:00.001-04:002010-06-29T19:59:02.781-04:00

Software developers have enjoyed the benefits of Test Driven Development for a long time now. System Operations professionals have not yet been test infected. Test Driven Development (TDD) allows developers to refactor and add new features with the security the impact of their changes are restricted to the intended components. System Operations professionals don't always have such a tool and rely

Maurohttp://www.blogger.com/profile/12233267053232498223noreply@blogger.com3tag:blogger.com,1999:blog-9206108663780220660.post-84312981487846562312010-06-01T22:44:00.000-04:002010-06-01T22:44:48.404-04:00

I share Michael Cohn's principle: component teams are not good and that they should be avoided [1]. One way I've been considering lately to avoid component teams is to create what I call private open source projects. Component teams are attractive to software developers. They make them feel that their component is a software product. This sentiment is a good thing if it wasn't for the company not

Maurohttp://www.blogger.com/profile/12233267053232498223noreply@blogger.com0tag:blogger.com,1999:blog-9206108663780220660.post-11532576074603979162010-05-03T21:24:00.001-04:002010-05-16T18:47:05.474-04:00

The product owner has a lot of responsibilities; one of them is to address 3 out of the 5 generally cited levels of planning. He or she is responsible for the Vision, Roadmap and Release Planning."The vision describes why a project is being undertaken and what the desired end state is (Schwaber 2004, p. 68 [2])." Without the vision, projects drift from release to release never fully achieving any

Maurohttp://www.blogger.com/profile/12233267053232498223noreply@blogger.com1tag:blogger.com,1999:blog-9206108663780220660.post-35630754795344677782010-04-04T12:41:00.001-04:002010-04-08T10:18:03.478-04:00

For years I insisted in automated unit tests with a naive assumption that if you take care of the pennies, the dollars will be taken care of by themselves. I even watched unit tests coverage numbers closely to make sure they were high enough, but still, the perceived quality of the software was not good. It turned out that “I was penny-wise and pound-foolish.” I couldn’t understand what these

Maurohttp://www.blogger.com/profile/12233267053232498223noreply@blogger.com1tag:blogger.com,1999:blog-9206108663780220660.post-24739480544974558892010-02-09T20:59:00.001-05:002010-02-14T12:20:20.698-05:00

Does it really matter if your Agile implementation is not ideal or complete? It does. However, it is more about the journey than the destination! Knowing your limitations and weaknesses will help you improve towards the goal of being more agile. In other words, it is important that you continue to inspect and adapt. There are multiple tools to help you evaluate the current state of your Agile

Maurohttp://www.blogger.com/profile/12233267053232498223noreply@blogger.com0tag:blogger.com,1999:blog-9206108663780220660.post-77761466555316278162010-01-04T20:41:00.001-05:002010-01-06T15:28:19.107-05:00

Matrix organizations deliberately creates a power struggle between project managers (PM) and resource managers (RM) causing the whole system to be dynamically unstable. In other words, energy in the form of conflict resolution must be spent to keep the organization stable and working efficiently towards business goals. There are three major types of matrix organizations: balanced, weak and

Maurohttp://www.blogger.com/profile/12233267053232498223noreply@blogger.com0tag:blogger.com,1999:blog-9206108663780220660.post-37509143880648862232009-09-23T16:42:00.000-04:002009-09-23T17:03:04.768-04:00

Keeping a team together is important, but not to the point where prioritization is hard.Shared services teams are a necessity and they won't go away. The problem with them is that backlog prioritization is hard. You need to identify a product owner that is effectively a proxy to all the other users. This proxy's job is thankless; he or she has to make multiple competing stakeholders agree on

Maurohttp://www.blogger.com/profile/12233267053232498223noreply@blogger.com0tag:blogger.com,1999:blog-9206108663780220660.post-23305527140053878662009-09-07T16:24:00.000-04:002009-09-07T16:29:32.019-04:00

If you are estimating story size instead of duration, velocity is what will allow you to determine project duration and thus cost. In such an environment, velocity is an important metric and needs to be monitored accordingly.As I wrote back in April, we have been collecting data to see if we were improving or not our velocity. My original intent was to find what influenced velocity however, that

Maurohttp://www.blogger.com/profile/12233267053232498223noreply@blogger.com0tag:blogger.com,1999:blog-9206108663780220660.post-83176310667006615662009-08-06T21:48:00.001-04:002009-08-06T22:02:23.220-04:00

If batch size is the number of lines of code being delivered to production, completely rewriting systems and waterfall have one thing in common: Big Batch Sizes.There are good reasons to rewrite your software. Like it being dependent on technology that is no longer supported [1]. The belief that the code is a mess in not a good one [2].When you make the decision to rewrite a system, your customer

Maurohttp://www.blogger.com/profile/12233267053232498223noreply@blogger.com0tag:blogger.com,1999:blog-9206108663780220660.post-14076746790978253552009-06-02T17:33:00.001-04:002009-06-02T17:47:24.588-04:00

How would you change your software development process if you had to deploy to production at the end of every iteration? Do you see yourself requiring "hardening iterations"?Deploying every iteration is not for the faint of heart. You need to ensure that the software you are releasing is solid and integrates well with the other pieces. It requires you to have your engineering practices really

Maurohttp://www.blogger.com/profile/12233267053232498223noreply@blogger.com0tag:blogger.com,1999:blog-9206108663780220660.post-20500384706997473792009-05-20T15:30:00.001-04:002009-06-02T17:48:13.012-04:00

People and Interactions Over Processes and Tools. In other words: Brain over Fingers.If Agile values people over processes and tools, why does it require so much automation? Reality is that people is good at creative tasks, so in order to really use their potential we need to free people from tedious and sequential tasks. People: We need your brains not your fingers!Perhaps my biggest challenge

Maurohttp://www.blogger.com/profile/12233267053232498223noreply@blogger.com0tag:blogger.com,1999:blog-9206108663780220660.post-77518447796796250592009-04-20T22:28:00.000-04:002009-06-02T17:46:47.550-04:00

As I’ve written before, we have been trying to identify metrics that will give us an idea of how much under control our process is. For that reason we decided to collect velocity, number of stories with definition of done, number of impediments per day, number of “distractions” and total number of team hours available.Even though velocity is not really comparable across teams and is easily gamed,

Maurohttp://www.blogger.com/profile/12233267053232498223noreply@blogger.com0tag:blogger.com,1999:blog-9206108663780220660.post-36867817463272249782009-04-08T14:46:00.001-04:002009-06-02T17:46:47.550-04:00

In my quest to satisfy a management request of coming up with metrics I came across Ron Jeffries fabulous article about increasing productivity.I couldn't agree more with his perspective that increasing productivity and metrics are not exactly coupled and that it is more important to adapt what you inspect to the problems you are trying to address. In other words, the metrics that you are

Maurohttp://www.blogger.com/profile/12233267053232498223noreply@blogger.com0tag:blogger.com,1999:blog-9206108663780220660.post-564426585383348442009-04-07T16:23:00.000-04:002009-06-02T17:46:55.223-04:00

We all know that metrics can be bad, specially if used for performance evaluations, but we need to be accountable as well.So here I start my journey on how and what to measure for an agile team.Here are a few links to start with:NCSS to Function Points conversion tableMeasuring Agility: Top 5 Metrics and Myths or the stream can be found here

Maurohttp://www.blogger.com/profile/12233267053232498223noreply@blogger.com0