tag:blogger.com,1999:blog-92061086637802206602024-03-05T19:57:52.916-05:00Working with AgilePractical approaches to Agile/Lean Software DevelopmentMaurohttp://www.blogger.com/profile/12233267053232498223noreply@blogger.comBlogger17125tag:blogger.com,1999:blog-9206108663780220660.post-26266040546551800582011-10-23T19:10:00.000-04:002011-10-23T19:10:11.808-04:00Velocity Assumptions: Take them into account when using it.Using story points and velocity have been practices for Agile processes for some time now. Velocity is observed as:
(A) velocity = story points completed in an iteration.By using velocity we calculate the remaining duration as:(B) number of iterations left = remaining story points / velocityIf you look at the formula above, one thing should jump at you: time is the only known factor. Story Maurohttp://www.blogger.com/profile/12233267053232498223noreply@blogger.com3tag:blogger.com,1999:blog-9206108663780220660.post-7186347900564878762011-06-24T21:13:00.000-04:002011-06-24T21:13:06.301-04:00Code Reviews and QualityAre code reviews the best way of building in code quality? Although good practice, code reviews do not assure quality, instead it inspects it. To build in quality you need to ensure your requirements are good, give your team members time and make sure they have the knowledge they need to build the software.
Test/behavior driven development increase code quality; it drives requirements to the Maurohttp://www.blogger.com/profile/12233267053232498223noreply@blogger.com1tag:blogger.com,1999:blog-9206108663780220660.post-22874615414106831132010-08-07T17:30:00.000-04:002010-08-07T17:30:22.305-04:00The Most Important Role in Scrum: The Product Owner - Part III 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.com1tag:blogger.com,1999:blog-9206108663780220660.post-74848027289240747602010-06-29T19:59:00.001-04:002010-06-29T19:59:02.781-04:00TDD for OperationsSoftware 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 relyMaurohttp://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:00Component Teams as Open Source ProjectsI 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 notMaurohttp://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:00The Most Important Role in Scrum: The Product OwnerThe 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 anyMaurohttp://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:00Quality is More than Absence of DefectsFor 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:00How Agile are you?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:00Do Matrix Organization Foster Bad Behaviors?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:00Team Preservation vs. PrioritizationKeeping 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:00How stable should velocity be?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:00Rewriting Systems and Waterfall: A Common Theme?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 customerMaurohttp://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:00Deploy Every Iteration?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:00People Over Process and ToolsPeople 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:00First Cut at MetricsAs 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:00Metrics and Productivity are not the same thing!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:00Agile MetricsWe 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 hereMaurohttp://www.blogger.com/profile/12233267053232498223noreply@blogger.com1