By now you probable have heard that John Deere is practicing Agile at scale. What was less then a 100 people doing it under the radar has now grown into over a 1200 and counting.
But, what does it sound like?
Are they having fun or is it just talk?
{ 0 comments }
The key to getting people open to learning about Agile is to have them experience it.
Say what? Yes, the trick is to get your attendees involved without you forcing on them.
But it gets better.
What if I showed you the steps on how to make this happen in any environment?
[Click to Continue...]
{ 0 comments }
Tomorrow’s advances in planting and harvesting operations, crop yield management, vehicle guidance and farm enterprise data management will be largely driven by Deere’s ability to rapidly develop and deploy new intellectual property, much of which will be embodied in software.
In enterprise settings such as Amazon, Google, Boeing and others, agile and lean software development methods have proven their ability to decrease time to market, as well as significantly improve quality and productivity of software development. To address the challenge of “developing more and better software, more quickly”, ISG is also adopting lean|agile development as its new software development paradigm
What Changes in Agile?
Agile development differs from its waterfall predecessors by dividing big projects into small deliverables that deliver value more quickly. Risk is mitigated as large projects are broken into smaller, more immediately evaluable increments. Funding is incremental. Software assets are built incrementally. As a system, software development is more responsive to changing market conditions. (For more insights on the rationale behind agile development, see http://www.rallydev.com/agileblog/2010/08/five-reasons-why-cios-should-consider-agile-development/).
Adopting agile development is a substantial change initiate for us. Functional silos between architecture, product management, development and test are broken down. Small, dedicated agile teams are being formed and aligned around products and features. The new role of “product owner” is being implemented to empower software teams to prioritize incoming work. Testing personnel are being dedicated to agile teams to accelerate the validation cycle. In this way, each small team has the ability and empowerment to “define/build/test” a thing of value for our customers. Teams are also being organized to deliver value in larger programs on an “Agile Release Train” model that provides cadence and synchronization of planning and software asset construction.
What Doesn’t Change in Agile?
While the teams and trains are empowered to deliver value, they do not, by themselves, determine the product and solution vision. That responsibility remains with product management and product marketing. However, the relationship with development is more tightly integrated with major initiatives aggregated around release planning milestones. Product, portfolio and program management must also evolve quickly to make crisper prioritization decisions and master the ability to break large initiatives into smaller chunks that can deliver value more quickly and avoid overloading the development teams with excessive work in process. So while these larger responsibilities don’t really change, the manner in which they are executed typically changes fairly dramatically.
Initiating an agile transformation at John Deere ISG scale is no small feat, but the business imperative demands we succeed. In order to thrive in the next decades, we must be as competent in building and deploying customer friendly software solutions as we are at building the worlds’ best agriculture and heavy construction equipment. At ISG, agile development is a big part of that equation.
If you would like to join our John Deere team, visit the John Deere career site and search for jobs in Iowa/Urbandale.
{ 0 comments }
As I promised, I would start blogging about the Agile rollout I am leading within my organization and describe how things are going so that others can learn just as I have learned from many others that have gone through the same experience.
The last two weeks was everything I thought it would have been. It included lots of excitement a few fears and everything in-between. Our scope of the first rollout was 120 people involved in 10-20 projects with all kinds of critical dates to other organizations. We also added 40 managers, some from my organization and some from other parts so that they can understand the change.
Managers were introduced to basic and advanced agile principals and practices, scrum as a mechanism for implementing team level software agility, agile technical and quality practices and the Agile Release Train as a means to provide strategic alignment and visibility across the organization. Teams were trained on similar topics, but focused on the Agile process called Scrum. Teams learned about backlogs, sprints, roles and how it will be applied at ISG.
In addition to training, 14 scrum teams built “Big Visible Informational Radiators” that are posted around the buildings that show their daily status and objectives of the next four weeks. These BVIR’s will serve as a communication means to the organization. These teams are not alone in learning Agile and are supported by two highly experienced qualified coaches to answer questions and help ensure objectives are being met.
Looking forward, we will monitor the status of these 14 teams and make adjustments that will be applied to future team rollouts. In addition to monitoring status and planning for the next wave, I will travel to Europe to engage more managers and teams on the model we are applying.
As for my retro on the first rollout:
Worked well:
Improvements:
Overall, I thought it went great and have received compliments. However, here is no real end to this Agile endeavor where execution will be flawless, or even “good enough.” I have entered a new Agile state where change is the norm, rather than the exception. Agile is not a destination, but rather a journey and I look forward to this journey we are on.
Take a look at the video from wave 1.
{ 2 comments }
Over the last 6 months I have been ratcheting up my communication on the benefits and success of Agile within my organization. We have been slowly working on it since November, but haven’t had much traction. In late May I decide to grab a hold of the steering wheel and push on the Agile gas.
Well, we must have been doing a good job at it that management is ready to take the jump and has given me and a few others the permission to roll Agile out to a larger group.
Choo, Choo, here comes the Agile train! Man, am I stoked!
The first thing I knew I had to do was bring in an expert that could help us develop a rollout plan and get us headed down the right path. After a week of phone call interviews to experts in the field of Agile, we decided to bring in Dean Leffingwell. Dean knocked our socks off during the interview and it felt like a perfect fit for our organization. .
Last week was the first official 2 day visit to Deere for Dean. Our goal of the visit was to start the tipping process, meet and convince management, excite and answer question for employees and get us started down the agile path. Mission accomplished!
So over the new few months I thought I would start blogging about rolling out Agile at Scale.
Here are a few pictures from Dean’s visit and attendees from the embedded group during my agile speech I made.
[slideshow]
{ 0 comments }
So last week we wrapped up our final regression cycle prior to releasing so I decided to have a project retro with all team members (product owners included). What no one knew is that I took probable 20 pictures over the course of the last 4 months as memories. I put these memories into a PowerPoint and asked everyone to write down what memories they had about that picture. Each team member wrote down on one sticky note what their thoughts were. Based on the sticky notes, we captured the top things we wanted to change, continue to do, or stop doing going forward. Here are some of the results.
Overall, everyone learned a lot and had fun doing it. Bottom line is LSSC10 was well worth it. Now, off to Agile2010 to learn some more.
{ 1 comment }
Here is what our board looks like today. DONE!!! Now the painful part happens; regression testing. Since we have maybe 10% code coverage we have to complete 100’s of manual test cases prior to shipping in July.
Each day a between tomorrow and July we will review what defects were found and make a decision whether we want to fix it or not. Ideally we will find nothing and ship this version, but most likely there will be a few defects found that will require us to fix.
{ 0 comments }
Today we did an exercise to see the benefits of setting Work In Progress Limits (WIP). The exercise is called The Airplane Factory Game.
http://www.agileway.com.br/2009/11/16/the-airplane-factory-game/
Here were our takeaways:
1) If a new request is added, it is easier to complete it if we have balance and WIP limits.
2) Having everyone work as fast as they can doesn’t work.
3) We also had a good discussion about adding requirements to something that is just about done. It’s better to file a requirements defect and fix it right away rather then moving that feature back to do. Right now our team struggles with requirements changing just as we are about to complete a feature.
Overall, it was a good team building experience and a lot of fun. Plus we learned something we can use in our work.
{ 0 comments }
The Lean Software & Systems Consortium Conference has inspired me to start a blog about my road from Waterfall to Agile. On Monday I plan to create a Kanban board.
Here were my takeaways from the conference:
Favorite Quote:
{ 0 comments }
Get smart with the Thesis WordPress Theme from DIYthemes.
Twitter
SlideShare
GoodReads
Email
LinkedIn
Youtube