The Agile Executive

Making Agile Work

Posts Tagged ‘Learning Agile

The Executive’s Workshop for Scaling Agile to The Enterprise

with one comment

Readers of this blog are well aware of my keen interest in enterprise level Agile. I am now offering a specialized workshop for executives on this topic.

The Executive’s Workshop for Scaling Agile to The Enterprise

This one day workshop and free follow-on coaching service prepares executives for their roles in large-scale Agile implementation.

This workshop is ideal for building a shared understanding of your company’s Agile goals and practices amongst members of the leadership team. It illustrates how executives could/should engage in the Agile process in a meaningful manner, and includes strategies for addressing common challenges.  Your team will see how to govern Agile effectively, and most importantly, you’ll learn proven practices for attaining the operational, financial and business benefits of a successful enterprise-level Agile implementation.

Objectives

Agile is shown to cut the cost, improve the flexibility and shorten time-to-market of software-driven projects. Upon completion of this service, executive teams will be able to:

  • Scale Agile to the enterprise level
  • Minimize risks associated with large-scale Agile rollout
  • Apply Agile practices in development and beyond
  • Galvanize the team around a shared, cross-functional Agile vision

Approach

The Executive’s Workshop for Scaling Agile to The Enterprise service is divided into three parts, each designed to help company leaders accelerate their adoption of Agile.

Part I: Preparation via phone interviews and web-based coaching. The workshop leader works with your executive team to gather context, discuss logistics and focus the on-site workshop on your needs.

Part II: One day on-site workshop is delivered through combination of presentation, examples, exercises and participant discussion.

Part III: Free telephone coaching and mentoring with the Workshop Leader for six months after the workshop. The objective is to help executives respond effectively to the challenges they encounter in the course of implementing Agile.

On-Site Workshop Details

Leading an enterprise adoption of Agile requires that you understand the key concepts, principles and practices of Agile without getting bogged down in technical details.  You must learn techniques for handling the expected “noise” associated with organizational change while identifying the critical tasks needing your attention and leadership to succeed. The workshop is designed to address these challenges with a minimal investment of time.

Here is an overview of the key topics you will add to your experience set:

Explaining the Rationale for Agile to Your Company

  • Why now?
  • What is the state of the art in Agile and what is our goal
  • Expected return on our Agile investment

How The Agile Process Fits into Your Company:

  • Understanding Agile as an example of  other common,  iterative, quality-oriented processes
  • How Agile works with other software development life cycle processes
  • How to run a heterogeneous software development environment that mixes Waterfall, Agile and other methods
  • Connecting Agile to your budgeting process
  • How to perform governance and portfolio management with Agile

How to Implement Agile:

  • Choosing suitable projects for Agile methods
  • Rollout strategies that mitigate risks
  • Keeping departments aligned during the Agile rollout
  • Defining the social contract for Agile
  • How to make Agile sustainable in your particular culture
  • How Agile impacts your partner eco-system
  • Succeeding with off-shoring and outsourcing

Setting Up The Agile Enterprise:

  • Determining your performance metrics for Agile
  • How to negotiate Agile contracts
  • Achieving breakthrough innovation through Agile
  • Business designs that utilize the power of Agile

Price and Availability

Paulo Coelho’s Good Counsel to the Agile Champion

leave a comment »

I am already used to the way things are. Before you came, I was thinking about how much time I had wasted in the same place, while my friends have moved on, and either went bankrupt or did better than they had before. It made me very depressed. Now, I can see that it has not been too bad. The shop is exactly the side I wanted it to be. I don’t want to change anything, because I don’t know how to deal with change. I am used to the way I am.

This magnificent paragraph from The Alchemist by Paulo Coelho, captures the nature of the Agile transformation better than any Agile book, article or presentation I had ever read, seen or listened to.  The issue for the team the Agile champion works with is not objectify-ing Cobol, calculating Cyclomatic Complexity or learning how to play Planning Poker. The heart of the matter is members of the team struggle with the innermost feeling “I am used to the way I am.”

I very much doubt that I can summarize Coelho’s counsel on the subject. It would be like trying to capture the wisdom and charm of Saint-Exupery‘s The Little Prince in 500 words or in 140 characters . To fully grasp Coelho’s good counsel, you will need to read The Alchemist cover to cover.

Depth in Seattle

with 2 comments

To summarize it in one word, the October 1 Rally Agile Success Tour (AST) event in Seattle, WA was deep. Broad spectrum of topics – from CMMI  and SOX to Lean and “Lean+”; very knowledgeable participants; insightful panelists; plenty of hard Agile data; questions on real needs; dialogues that led to unexpected findings; and, 1-1 meetings focused on actions that could/should be taken after the event. Just like the recent AST event in Boston, MA, there was vibrancy in the air.

Getty’s Jeff Oberlander quantified the progress they made on fairly large scale releases (~900 user stories), shortening time-to-market (TTM) from 24 month to 4 months. He indicated this impressive change in time-to-market occurred in parallel with improvement in quality. Reader of this post might want to take a look at Chapter 1 of Agile Project Management by Jim Highsmith for a quantitative analysis of the correlation between the two (TTM and quality).

The impressive results reported by Jeff were supported by the classification given by Liberty Mutual’s Steven Johnson. Steven observes three kinds of projects, as follows:

  • Grass roots initiatives. Such projects typically lead to: {New TTM = 2/3 Old TTM}.
  • Organized pilots. Such projects typically lead to: {New TTM = 1/2 Old TTM}.
  • Overall R&D transformation. Such projects typically lead to: {New TTM = 1/3 Old TTM}.

From what I know of David Rico’s forthcoming book The Business Value of Agile Software Methods, the results reported by Steven are consistent with David’s findings.

Boeing’s Ryan Kleps focused on the impact of Agile methods on developer satisfaction. He presented the following data from a survey conducted in Boeing:

  • 30% improvement in satisfaction with respect to tools
  • 25% improvement in satisfaction with respect to involvement
  • 10% improvement in satisfaction with respect to trust

Interestingly, Ryan indicated that various “pirates” were starting to do Agile at Boeing as a result of the higher level of satisfaction noted above. We did not have the opportunity to cross-correlate data from Boeing with data from Liberty Mutual. My intuitive sense is that Ryan’s “pirates” and Jeff’s “grass roots initiatives” are synonymous.

thePlatform’s Reena Kawal and Microsoft’s Stein Dolan provided insights that are not often reported. Reena analyzed the much improved ability to assess trade-offs from a customer perspective. Stein highlighted how effective emulation can be in enabling teams to deal with code that has not been written yet. Their thoughts were vividly complemented by the 4X100 relay race metaphor given by Ryan: only 1 sprinter “works” at any point in time, while 3 are “idle”. Yet, there is no faster way to get the baton to the finish line…

One part of the event that was particularly gratifying to me was the role playing during the breakout session entitled “Socializing Agile with Your Executives.” Stein and I played the role of mean executives who do not get Agile. Participants in the session who played the role of the inspired Agile champion beat us up pretty effectively. As a matter of fact, one of the participants – CyberSource’s Tom Perry – gave the report from this breakout session to the whole audience when we reconvened. He delivered a very effective “why you should do Agile in spite of all your misgivings” message.

As indicated in a recent post, the AST “train” stops in Chicago, IL on the 15 of October. We are quite likely to address specialized topics that have not been brought up in previous events. The makeup of the panel in Chicago is unlike any of the nine panels I have prepped so far…

Toward Vertical Approach to Agile

leave a comment »

Yesterday we held a great Rally Agile Success Tour (AST)  event in Seattle (which I will describe in a subsequent post). On the 15th we will be doing the AST event in Chicago. This post is about an intriguing element of the forthcoming Chicago event.

Every one of the 9 events we held so far (click here for sample video clips from the events) was unique in some ways. The demographics in Atlanta, GA were not like those in Boston, MA. The issues brought up in Los Angeles, CA were different from those in Washington, DC. The panelists in New York, NY addressed a set of topics that did not come to the fore in the Santa Clara, CA event. Each event was characterized by locality of reference – topics, discussions, breakout sessions and 1-1 meetings that were of relevance and importance in the context of the local Agile community.

Having worked with the Chicago panelists in preparation for the forthcoming event, my sense is that we will immerse the participants (and ourselves, of course) in a set of Agile/Lean challenges that could be quite different from those we addressed in other cities. Some very unique companies are represented in the panel we will hold in Chicago.

I actually consider Chicago on the 15th a potential pivot in deepening our understanding of the way Agile applies to various verticals. We are progressing from a horizontal approach to applying Agile toward a more vertical assimilation. The differences between the two might be subtle, but they are all important for the success of the Agile champion.

Written by israelgat

October 2, 2009 at 11:37 am

Posted in Events

Tagged with , ,

Richness and Vibrancy in Boston

with 2 comments

A blog post can’t do justice to the richness and vibrancy of the dialogs that were produced by 80 participants in the September 17 Rally Agile Success Tour event in Boston. You had to be there in order to fully savor the experience. If you are a Boston Agilist who missed this gathering, the event in Chicago gives you an opportunity to catch up without needing to fly all the way to the forthcoming events in Seattle or London.

Agile metrics reported during the event were very impressive.  AOL’s Jochen Krebs indicated acceptance of user stories improved from 20% to 90% in one year! Sermo’s Rob Sherman provided the following three year data:

  • 2007: 10 releases; 26 patches
  • 2008: 29 releases; 32 patches
  • 2009: 67 releases; 0 patches

(“0 patches” is not a typo – year-to-date “patches” at Sermo have primarily been about laying the required infrastructure for forthcoming releases to be deployed, not about bug fixing).

The quantitative data was nicely complemented by qualitative insights. ITG’s Heather Kanser’s work on the Virtuous Cycle of Agile and Constant Contact’s Rick Simmons contrasting Informational Metrics v. Motivational Metrics demonstrated ahead-of-the-power-curve thinking. 

One other thread that came to the fore during the event was Agile Business Service Management (Agile BSM). Think of it as the fusion of Agile methods for software development with state of the art practices for managing IT from a business perspective. Embryonic that this trend is, the potential impact is huge. We will discuss this emerging trend in forthcoming posts.

It is a pleasure writing this post!

Written by israelgat

September 20, 2009 at 6:59 am

10 Steps for Setting up an Agile Start-up

with 4 comments

Mapping the Agile thinking, theory and practices to the realities of the target company is a tricky part of making Agile happen in a sustainable manner. HubOne’s Nick Beaugeard, known to readers of this blog from his post Enterprise Product: $50,000 and 8 months – You Must be Kidding, shares with us his recipe for so doing in a start-up environment. He manages to weave the pragmatic details with the core principles behind software development in general and Agile methods in particular. For example, consider the following insight provided by Nick:

In fact, when developing an API, the unit tests are your clients!

Readers of this blog might want to compare and contrast the thoughts Nick expresses in this post with those of:

  1. Ryan Martens on prescriptive versus adaptive rollout of Agile (click here).
  2. Eric Ries on iterating on the problem definition and developing the customer base in parallel with iterating on the solution (Click here).

Here is Nick:

After my last post, where I discussed the concept of implementing the tools and process before you get people on board, I though it appropriate to provide some prescriptive guidance on how we achieved the process. This post is primarily aimed at start-ups where you have total control over your infrastructure, computers, network and internet connection. If there is enough interest, I’ll produce another post of how to perform the same, but in a corporate environment.

I believe, and my experience has shown, that preparing your work environment, tools and process before the team starts coding helps eliminate costly and lengthy discussions about tools and process. In fact, in my experience, most developers are pleasantly surprised to find the environment ready and working and slip into the processes extremely quickly.

So, please find below my ten steps. Following this process really helped us get up and running quickly. Whilst we used Microsoft Development tools, this equally applies to their open source equivalents, so feel free to substitute specific tools, just not the requirements and process.

  1. Authentication, Network and VPN. Setting up the core of your environment is critical. As you are more than likely working on secret software at the outset, you need good, auditable mechanisms for authentication and logon. In addition, we don’t want our developers to have to do anything except start their PC or laptop and login, and we really want them to be able to work remotely. If you don’t feel qualified or able to complete the steps below, any good local IT Pro should be able to set this all up for you. To perform this, we implemented the following:
    1. Network Connection – we are in Australia so our networks are not fantastic. We subscribed to a good ADSL 2+ plan (24Mb) with a 80Gb limit. We implemented a modern ADSLwireless modem/router and configured it correctly. This gave us acceptable internet connectivity.
    2. Domain – We implemented a domain controller running on Windows Server 2008. This gave us corporate authentication, auditing and identification. The domain controller was hosted on our private network (see 1.c)
    3. Routing and VPN –our internal development network needed to be protected from internet connectivity so we implemented a Windows Server 2008 machine with two network cards (called multihomed). One card was connected to the router and one connected to an Ethernet switch. We used a private IP subnetfor our development Local Area Network (LAN) and enabled Microsoft Routing and Remote Access. This gave us the ability to authenticate domain users to VPN into the private network for remote working. We then configured our router to allow access to the server for VPN Access.
    4. DNS –one of the issues you face with ADSL is that your Internet IP Address changes often. The solution for this was to use a solution from DYNDNS (www.dyndns.com) which allowed us to register a host name, coupled with a client application which ensured our host name for VPN always pointed at the correct IP Address.
    5. DHCP –it’s a real pain, especially when using VPN when your client machines are configured for static IP addresses. We used Microsoft Dynamic Host Configuration Protocol (DHCP) to ensure every machine had a unique IP Address and that our networking became just “plug-and-play”
  2. Version Control and issue tracking – in my experience, there are four critical systems needed for any software development team. These are:
    1. Version Control – Also known as source repositories, these systems allow control over check-in, check-out and versioning of source files. I cannot recall the number of times we backed out an individual source file to a previous “working version”. Without this in place, I can guarantee you’re going to struggle maintaining a good code base!
    2. Bill of Materials– the way I use these is to highlight each of the key deliverables in a project. When building Enterprise Profile Management, our BOM had 345 separate items, everything from the corporate website, to graphic design, to core components of the API. The Bill of materials is a way to track the overall progress of the project. Each item in the Bill of Materials should have at a minimum a title, description, owner, due date, % complete and %tested. We also use the bill of materials to determine our release criteria (more on this later).
    3. Build System – the biggest mistake a development manager can make is to not build the software regularly. We build our software system every time there is a new check-in (called continuous integration). Even with a very small team, the ripple effect of changes could go un-noticed for ages without building regularly. As an aside, we also have a Nabaztag (www.nabaztag.com) bunny which tells us whenever there is a build, whose check-in caused it and whether it succeeded or failed. While this is really annoying, it focuses the developers on good check-ins. We might also make the person who broke the builds buy us a round of beer, but that’s a secret!
    4. Issue Management – More important than email, IM, or indeed any other form of communication in the development team is issue management. I believe that in  a project of any size, you’ll be hard pressed to ever finish if you don’t have good issue management. Issues should contain a title, description, history, assignee, status and indicate which version/iteration of which product the issue applies to. I don’t actually think a spreadsheet will cut it here. If there’s one investment you make, make sure it’s issue management.
      We used Microsoft Visual Studio Team System for all of the above. Being an ex-microsoft product team member, I am familiar with the way the product works, but there are lots of plug-ins available for scrum, agile (MSF) and CMMI. To do this on a startup budget, we were able to join the Microsoft BizSpark program (http://www.bizspark.com) which gave us instant access to Microsoft’s developer tools. I’d highly recommend taking a look at that program!
  3. Backup – Now is the time to do a backup and recovery operation. You have no real data in the system and how you installed it all is probably fresh in your mind. Trust me, every first recovery operation fails. You need to imagine your office has been hit by lightning and you have no servers, and just a backup. If you can successfully recover your environment in under 24 hours, you’re in a good place. Document how to do it and test it regularly.
    When we were developing Enterprise Profile Management, our server with all issue management, reporting, builds and version control failed (the processor fried). We were taking backups, but the restore failed. It took me 22 hours to perform a forensic recovery of our production platform. Luckily the developers could work offline, but we still introduced a ton of integration bugs. Don’t skimp on backup.
  4. Email, IM and Web Conferencing – You’re going to be working remotely at some time, whether you think you will or not. We quickly implemented the following tools:
    1. Email – Google Gmail for your domain (www.google.com/apps)
    2. IM – Windows Live Messenger and Skype (www.live.com, http://www.skype.com)
    3. Web Conferencing – Dim Dim (www.dimdim.com)
      Note: there are lots of other tools out there, we just chose these (with little science, but they’ve worked well for us)
  5. Coding Standards – Getting at least some coding standards in place before you write any code is really important. Good Version Control Systems should be able to validate code against your standards on check-in. My key coding standards are:
    1. No String Literals – All strings must be externalised in resource files for later localization (a process called globalization)
    2. Commenting – I insist that every class, method, property, event and interface be commented. There’s method in my madness here; obviously code commenting is important but with proper commenting (especially in C#) and tools like sandcastle, you can automatically create documentation like ours at http://api.hubone.com.
    3. No Short Cuts – This one was a little contentious – Our code will in the future (hopefully) be worked on by people who had no idea of the concept. Writing out If…then constructs and property accessors in long-hand makes the code much more readable for novices, junior programmers, support teams and architects alike.
    4. Unit Test Everything –I insist that every method, property, event etc, etc has an associated unit test. These we execute as a part of the build. My goal is to have over 80% of any code written covered by unit tests. In fact, when developing an API, the unit tests are your client! Although this increases the programming effort up front, it actually reduces the total time taken to ship the product. I havelost count of how many times our massive unit test library has saved us from nasty regressions that we could never have found from UI testing.
  6. Write some code –Don’t worry, you don’t need to be the world’s best developer to write some code. All you need to do is think carefully about the different items in the Bill of Materials and start prototyping the methods, properties and events that will make it all work. Ensure you adhere to your coding standards. The goal of this exercise is to effectively build a skeleton of your application before the developers get on board. This can make them hyper productive when they start. They’ll probably end up getting rid of every line of your code, but it will get them in the rhythm of how you want the platform to look. As the architect of our platform, I used this period to prototype and test all of my assumptions of how things would work. By the time the developers got on board, I had a passable working prototype of an API with unit tests and coding standards, although there is almost none of my code in the final product, this enabled us to get running really quickly.
  7. Don’t write a test plan – Write the user documentation instead, and use this to test your application. That way you’ll know your application does everything the user guide says it does and you won’t double up on a test plan and the user guide (which should end up being pretty similar anyway). I wrote our user guide because I knew what I wanted the product to do and it’s also a fantastic way (sometimes they only way) you get to communicate with your customers.
  8. Give ownership, responsibility and praise – You will have no choice. As you get developers, testers, writers and others on board, you must give them ownership of components. I find that if I give someone total ownership, they always deliver. People are proud when they do great work and if they feel and really have ownership over something, it will be their best work. Not only that, but they’ll pull out every stop to impress you, the team and your customers. If you hire correctly, you’ve got great professionals in the team. Respect them as professionals and the results will be awesome.
  9. The best wire framing tools are not wire framing tools – You’re a start-up, right? Then you’ve discussed your ideas with potential customers and you deeply understand their needs. You could sit down with any number of wire framing tools and attempt to design components. How about you take a different approach? Write functional code which does what you (and therefore your customers want) – Developers find it far easier to code from a working model and they can re-use portions of your code. All of this streamlines the process and you can take your models to customers (with caveats on your poor coding skills and lack of stylistic ability).
  10. Constantly review and drive – We spend some time every day in front of a whiteboard discussing options, vision, checklists and almost everything else, but in a start-up, it’s not really a democracy. I run my start-ups like a benevolent dictatorship – I hold the final decision, but let everyone have input. I’m the one talking to customers, and sometimes I bring customers in to explain a requirement, but at the end of the day, how it works is up to me (I have the most to lose if it doesn’t work!)

Notice here, we never had a specification, requirements specification or design, we build the code a piece at a time and made it work. We’ve gone back and documented some core functionality, flowcharts and features, but at the outset, it’s more important to make it work. I’ll share a caveat, though, I’m also the software architect so I can hold the requirements for scalability, security and reliability, and guide the team to accomplish those goals.

Hiring the team can happen sometime between points 7 and 8, I don’t recommend you do it before!

If you’d like more information, please feel free to get in touch at nick@hubone.com, and if you’d like a copy of the software this built, we can be found at http://www.hubone.com.

Interview with Jim Highsmith

leave a comment »

InformIT has just posted my interview with Jim Highsmith. While the interview naturally focuses on the the new edition of Agile Project Management, Jim makes quite a few observations on deep truths. For example, in response to my asking him to do a quick “retrospective” of the period since he signed the Manifesto, Jim gives both perspective and retrospective. Here is an excerpt from his answer:

If the Agile movement is to continue, we have to better understand what the core Agile principles really are, and not just our personal interpretation, and then find ways to incorporate thoughts and ideas that may seem in conflict with our own ideas. Just because some Agile camps may have a more widespread audience, that doesn’t make them the source for all things Agile. The essence of change is tolerance for new ideas that conflict with our own.

Enjoy reading the full interview!

Written by israelgat

August 17, 2009 at 8:21 am

Preliminary Assessment of “Ask an Expert”

with 3 comments

Just about three months ago we started an “Ask an Expert” service for Agile practitioners in Austin. The service was defined as follows:

The objective of the Ask an Expert program is to provide free consultation by experienced Agile Austin coaches to any Austinite that wrestles with issues related to promoting, planning and executing Agile methods. The program will address the needs of practitioners in companies that produce software, embed software, or use software as an integral part of their business processes. In addition to 1-1 consultation, coaches will gladly hold discussions with entire teams.

Ask an Expert sessions should be primarily regarded as a step toward addressing concrete Agile issues that manifest themselves in a specific environment. Coaches might not be able to complete a comprehensive analysis, but will make certain to suggest what the heart of the problem might be and point out Agile resources that practitioners could use on their own.

To ensure available access to experts, consultative session time will be divided between attendees. Team discussions with any Agilists attending the program will be encouraged to maximize the sharing of experience and draw out the wisdom of crowds. One-on-one sessions are available on request, but will be time-limited based on attendance (15 minutes typical).

The program will strive to balance utility with fun. Utility will primarily be delivered through actionable insights; fun will be had through passionate exploration of Agile topics in a friendly and collaborative manner.

Our experience over the past three months indicates:

  • A broad spectrum of question/topics has been brought up. Most of the questions revolve around the “hows” of Agile. Some questions address the “whats” of Agile. Precious few get into the “whys” of Agile. Click here for details.
  • Majority of questions apply to the project team level. Only a few address enterprise level issues.
  • Many questions (and the discussions that follow) are actually about the software engineering fabric, not about Agile per se.
  • The “all singing all dancing” format of the sessions seems to work pretty well. It often leads to uncovering questions/issues we had not thought about before.
  • Having said that, we do not really know at this point in time whether some of the participants would have preferred a more traditional 1-1 format.
  • Most participants seem to have already been sold on the benefits of Agile. We do not usually get folks who are struggling with “Waterfall v. Agile” questions.

Most gratifying, some early “return on investment” indicators have been noticed. For example, one of the participants was so kind to send the following note:

Thank y’all for your help with my presentation about Agile to my VP. The meeting went well and we are moving forward with Agile. I’m going to work on a mock-up of a release and project, to show what Agile release planning and budgeting would look like. I’ll get buy-in based on this mock-up from the directors, then move on to a pilot project.
 
This is a huge step for… [company name deleted by IG], one I wouldn’t have predicted 6 months ago. The information and resources available through Agile Austin were essential in making this happen. Thank you for your help!

Written by israelgat

July 13, 2009 at 12:17 pm

The June 25 Agile Success Tour Event in Atlanta

with one comment

Having finished my prep meetings with panelist in the forthcoming Rally Agile Success Tour day in Atlanta, I anticipate the event will be really rich in content. The panelists will bring up various actionable insights in quite a few Agile/Lean areas. Here is a sample of some of the more intriguing topics that will be highlighted by them in the course of the event:

  • Agile metrics
  • Return on investment considerations
  • Painless cost accounting in Agile
  • The “All In!” rollout strategy
  • Sustaining the Agile momentum over a prolonged period
  • Succeeding with insanely distributed teams
  • Requirement Driven Agile Development (RDAD)
  • ‘Secret sauce’ for large scale Agile initiatives

The dynamic nature of the event will no doubt lead to many additional topics and insights. Much of the content in the recent Rally event in Santa Clara was generated by participants sharing their explorations, experiences and thoughts with one another. It is a very effective way to learn.

The event is characterized by a high concentration of decision makers: 44% of participants will be in the VP/CXO/Owner category; 40% in the Manager/Director category.  It will be meaningful to you whether you are an Agile champion or an Agile decision maker. As a champion, you will get immersed in the issues your executives are wrestling with. As a decision maker, you will acquire deeper appreciation of the operational, financial and business advantages Agile methods enable.

Please introduce yourself to me in Atlanta If you are a reader of this blog. It is a great opportunity to “touch” each other!

Written by israelgat

June 20, 2009 at 2:24 pm

Posted in Events

Tagged with ,

Questions from “Ask an Expert”

leave a comment »

I had the pleasure of participating in the May 7 and May 14 sessions of the Agile Austin “Ask an Expert” Service. You can read the questions/topics brought up in these sessions by clicking here. Following are two observations from the questions cited so far:

  • Enterprise readiness issues are rarely understood, let alone addressed in advance of an Agile roll-out. The focus on the “hows” of the process seems to consume the energy of the Agile practitioners. Precious little is left for the “whys.”
  • Many questions (and the discussions that follow) are actually about the software engineering fabric, not about Agile per se.

The two are actually related. It is too easy to try to boil the ocean if you do not think of Agile as a single “layer” in the overall software engineering fabric, pretty much along the lines one thinks of a layer such as Transport in the OSI Model. Needless to say, trying to boil the ocean can consume you to the point nothing is left for the deeper understanding of the “whys” of Agile.

The reader is encouraged to take a look at the post entitled The House Jim Built. The two views of Agile given in this post by Cutter consultants Jim Highsmith and David Spann capture the essence of Agile in a lucid manner. You can start with either of the two views, using the one you prefer as a guide to placing Agile in the bigger picture.

(Please note Anne Mullaney‘s kind offer in the thread accompanying the post to send the full copy of Jim’s E-Mail Advisor to readers of the blog. David’s Research Report is in the public domain).

Written by israelgat

May 18, 2009 at 4:51 pm