Tapestry for Nonbelievers
A new article by I. Drobiazko and R. Zubairov introduces v. 5 of the Apache Tapestry component-oriented web framework. The tutorial shows how to create a component and covers IoC in Tapestry and Ajax.
Tracking change and innovation in the enterprise software development community
Posted by Amr Elssamadisy on Jun 05, 2007 08:00 AM
David Anderson described how his team is using a kanban system for their sustaining engineering (maintenance and bug fixing) activities. Iterations have been dropped although software is still released every two weeks. Work is scheduled, monitored, and run via a "kanban board" and daily stand-up meetings.
Kanban comes directly from the Toyota Production System and Lean Manufacturing and is an Information Radiator that is used as the touch point for a team to coordinate tasks through production. This is an idea that is not new to Agile - although obviously it did not originate from our community. What Anderson and his team have done is an excellent example of applying ideas of Lean Production principles to remove, previously necessary, waste from the system. Do we really need the planning, estimation, and other overhead for Iterations when in the maintenance releases?
It uses a kanban system to pipeline change requests (CRs). When a CR is complete it sits in the Release Ready state until a scheduled release happens on every second Wednesday.
This approach also removed one common constraint with Iterative development, that all problems have to be broken down to fit into one Iteration:
The kanban system also frees us from the constraints of time-boxed iterations. Even though we are making a release every two weeks, items in the system can take up to 60 days to move through depending on their size and complexity. Items that would be too big for a single two week iteration can still be fed in to the system and will work through and be released without any special management attention.
Those are the positive aspects of this method. However, is this a technique that is responsive to change? There are no synchronizing points such as demos and retrospectives to provide feedback about the process itself. That said, Anderson's team has already diagnosed one problem related to team members working remotely:
Well it turns out that keep them in sync is problematic especially when people are working from home or otherwise remotely. Darren Davis has instituted a "sticky buddy" scheme where people who are WFH for the day, have to designate a in-office buddy who will update the white board for them and keep it in sync with the electronic tracking system.So it seems their team is able to obtain feedback using the daily stand-up meeting. Will this continue to be enough?
IBM Agile Development eKit: Free Articles, Expert Q&A, Educational Resources
Fighter Jets and Agile Development at Lockheed Martin (Case study)
IBM software architect eKit: Grady Booch podcast, whitepapers, articles
I have seen this work with small, experienced teams that have mastered communication methods. They are communicating all the time and have 'grocked' this way of working. I have also seen teams discuss doing this when they feel pain from Iterations. Instead of solving their problems with Iterations, they want to avoid them. (The same reasoning that goes behind integration at the very end of a release.)
I'm most curious about the approach to features that span releases; are these managed with feature branches, or developed such that they cannot change existing functionality until they have been completed? Ultimately, I'm not convinced this approach offers a significant benefit over iterations, although I'm not against it. I'm inclined to believe that a staged pipeline like this works well in some environments, although I've mostly considered using this in gathering requirements rather than implementing software.
This system *is* responsive to change, with the expedite slot. It is also allows innovation, as well as specialized roles on the team. I am using it, and I've seen it increases communication and collaboration. I think it allows a team to lean into agile, as it were.
A new article by I. Drobiazko and R. Zubairov introduces v. 5 of the Apache Tapestry component-oriented web framework. The tutorial shows how to create a component and covers IoC in Tapestry and Ajax.
In this interview, Burton Group consultant Pete Lacey talks to Stefan Tilkov about his disillusionment with SOAP, his opinion on REST, and addresses some of the perceived shortcomings REST vs. WS-*.
Jay Fields presents his concept of Business Natural Languages - a type of Domain Specific Languages geared towards being readable by domain experts.
Adoption and interest for Distributed Version Control Systems is constantly rising. We will introduce the concept of DVCS and have a look at 3 actors in the area: git, Mercurial and Bazaar.
Deborah Hartmann interviewed Segundo Velasquez about his experience as customer with an Agile team during the initial phase of software design of a product.
David Cooksey shows how to fine grained versioning to a ClickOnce deployment using an HttpHandler written with ASP.NET, making partial rollouts to a test audience much easier.
Windows workflow (WF) is an excellent framework for implementing business processes, but lacks support for human activities. This article describes a completely generic approach for changing this.
In this interview taken during OOPSLA 2007, Markus Voelter talks about the importance of documenting the software architecture, and gives some good and also bad examples on how it could be done.
3 comments
Reply