The Role of the Agile Architect

We’re Agile, we don’t need no stinkin’ architects!

It would seem that Agile principles are in direct conflict with a traditional software architect role — in an agile project, where the creation of working, tested code trumps everything else, nothing separates architecture from design and implementation. They are all wrapped up together in the practices we use to produce the code.  Instead of traditional documents and diagrams, the architecture is going to be exposed through the software itself…

So what does an Architect do in an architecture-antagonistic TDD/Agile/XP shop?

Mark J. Balbes, PhD recently shared his experiences as an Agile Architect, and it was so compelling we just had to share.

Architecture Is a Frame of Mind

To Mark, architecture is a frame of mind. There is no room for an “ivory tower” architect that sits at a desk creating diagrams and making architectural rules for development teams to follow. Agile development favors person-to-person communication over written documentation. If you’re an agile architect, the best place to be is in the war room with the development team, working alongside them every day.

The architect’s role, then, is not to dictate to the team, but rather to guide, mentor and cajole the team in the right direction.

The War Room Is Where It’s At

The hustle and bustle of development is exciting and provides almost everything Mark needs to do his job. In the war room, Mark can listen to what is going on with the team, shepherd the team to keep the software development moving in the right direction and mentor team members on the concepts they may not be familiar with. Continue reading “The Role of the Agile Architect”

Agile Adoption Growing in India – What about the rest of Asia?

ThoughtWorks recently published a new survey about the “Agile Adoption in India – Survey 2011” carried out earlier this year in partnership with CIOL to understand the Agile adoption trends in business and IT in India.

The survey captured responses from 770 IT practitioners and executives from 330 organisations across the country.

The survey results provided some key insights into Agile adoption trends in India.

Most organisations following the Agile methodology experienced significantly faster time-to-market of 68%, with 68% more adaptability to changing requirements from clients and improved IT productivity and quality, which led to a better ROI of 60%, and an increased project visibility of 60%. 

Key areas of concern when adopting Agile included internal IT opposition (53%) followed by insufficient expertise, in both coaching and leadership (41%) and difficulty in finding engineering talent (36%).
Of the respondents, 39% had moderate experience working on Agile practices, while 14% affirmed being experts; 84% who were early champions of Agile belonged to the management and executive level, while 44% worked in organisations using Agile practices in some projects.
It was interesting to note that the maximum number of respondents came from Indian and foreign MNCs.
“The results showed that progress towards Agile is being made, but that adoption must be carefully managed to introduce and embed all relevant practices, otherwise anticipated benefits might not be realised.” – Sudhir Tiwari, Managing Director, ThoughtWorks India.
So tell us, ThoughtWorks, what about countries like Japan, Korea, and China??? I wanna know!

[HT: ThoughtWorks]

Lean Agile in Construction Projects – 9/11/11 – 10 Years Later

I spent 2 fulfilling hours watching Discovery Channel‘s show on building the new Tower 1 of the World Trade Center called “Rising.” The commercial free special was especially poignant because of the many stories of individuals effected by the 9/11/2011 twin towers falling, and their calling to help re-build Ground Zero.

“The whole world is looking at us and our response to the tragedy.”

Essentially, the story revolved around the contruction of Tower 1 and the goal of building it up to 1000 feet  before 9/11/2011 (1776 feet at completion in 2013).

  • They have to build 1 floor per week. – Sounds perfect for iterative development...
  • 8 different construction contractor gangs work on every floor. – Team dependencies...
  • The Iron Workers start with the work, led by Mike and Tommy from the Raising Gang and the Mohawk Indians who have been building the New York skyline since the 1880’s.
  • Steve Plate, the Director of WTC Construction, oversees all of the construction. He lost 84 co-workers on 9/11/11. – He is the Uber Product Owner.

“Failure is not an option.” – Steve Plate

While watching this TV special, I absolutely had to open up my laptop and take notes (am I an Agile-nut or what)? My thoughts, through the entire show were:

“I want to see how they built this thing! I want to know if they took an Agile/Lean approach!!!”

After watching the entire special, they had not fully revealed their build process, so I decided to do some research on whether Agile and Lean techniques work in construction projects. I did:

“To be agile an enterprise or project must be structured appropriately to proactively and quickly adapt to change, seizing such opportunities to enhance value outcomes. It should be noted here that ‘lean construction’ contains some aspects of both lean and agile production and the ‘Last Planner’ method (Ballard, 2000) can even be seen as partially agile. An alternative and interesting view of merging lean and agile techniques (‘leagile’) has been proffered (Naim and Barlow, 2003); however, this only considers the ‘pull’ nature of agile customer demand on the lean construction supply chain and does not embrace APM holistically.” – Robert Owen, Lauri Koskela, Guilherme Henrich and Ricardo Codinhoto on “Is Agile Project Management Applicable to Construction?”

So, does Agile and Lean work in Construction Projects? Continue reading “Lean Agile in Construction Projects – 9/11/11 – 10 Years Later”

Retrospective 47 – Gotta Love Them Tools



[Tool Review] – Concept Board – Next Level Design Sharing

We here at Agile Scout love us some design and Agile. We talk a lot about how design and Agile can work:

Not only that we love how developers are creating design apps that make it easier for teams to collaborate:

  • [Tool Review] – Wirify – Make a webpage a wireframe
  • [Tool Review] – GoMockingBird – A light wireframe tool to put web-centric wireframes together quickly
  • [Tool Review] – CageApp – Design sharing made easy
  • [Tool Review] – Lucid Chart – Online Diagramming made easy
  • Or go with a regular design pad – Yep. Pen and Paper version.
  • How about turning a wall into a full-on whiteboard. Use Idea Paint!

Well here’s something for Agile developers and designers!

[Enter]: Conceptboard A brand new (free) cloud app for visual collaboration *Agile Scout likes!

Conceboard offers a blank work space (like a whiteboard) on which you can put designs, pictures or documents (pdf, ms office). Or you just start to scribble (great for mind maps and brainstorming). With the comment tool you can place annotations directly at your designs or concepts.

Their distinctive feature is real time collaboration.

Teams can work at the same time on a board. Even on the iPad. There is also a great presentations mode for showing your work to a customer, coworker or friend. Conceptboard offers a typical, simple interface for the online feedback tools, in order to collect comments and remarks at one central location. This central location is the board which is easily accessed by all participants via a browser; in other words, the current status of the draft and all the participants’ opinions are available to everyone at all times. The feedback in the Conceptboard can consist of adding text, or scribbles and small sketches, or even adding other files and screenshots to the same board.


But before we continue, we had to let you know that all AgileScout readers get 20% off a premium account! Thanks to Roman for this awesome perk.

Just use the coupon code “agilescout”


Not only that, for the we will choose 3 random WINNERS  who want to try out the design app get a 6 month license for FREE! 

Just comment and let us know how you’d use this app for your personal or business use!

What I loved about this tool is it’s fluid and easy to use. All about the simplicity! Adding and uploading documents was a breeze, I was even able to add screenshots directly to it. 🙂 Continue reading “[Tool Review] – Concept Board – Next Level Design Sharing”

[Tool Review] – LeanKit Kanban – Optimize Your Flow

[We review Agile tools. Have you seen our Agile tools list?]

Kanban is kicking into high gear these days as more and more enterprises are taking on the challenge of utilizing Kanban to help them visualize their business. It’s just a matter of time before some really good Kanban tools come out to help. Lucky for us, they have. 

[Enter]: LeanKit KanbanOptimize Your Flow of Work

After you sign up for a 30-day free trial, you’ll have access to a simple dashboard. Get started with a few clicks and you’ll be on your way to creating your board:

The board is so intuitive and simple to use. Simply add a story, fill in as much information as you need into the card and save it! Continue reading “[Tool Review] – LeanKit Kanban – Optimize Your Flow”

[Tool Review] – Opzi – Collaboration Platform Featuring a Wicked-Fast Interface

[We review Agile tools. Have you seen our Agile tools list?]

We love us some neat tools. Not only that, we love pre-launch beta invites, and that’s exactly what we got. There is something about VC-funded startups that just tickle us, or rather, get our blood moving. It’s an exciting prospect to say the least. We at Agile Scout were lucky enough to get an early look at Opzi’s new product, which bills itself as a “next-gen collaboration platform,” featuring a library of apps that can be installed with one click. So what is this all about?

[Enter]: OpziCollaboration Done Wickedly Fast

After entering into the private beta we were greeted with a simple Install page.

The first two apps available are (1) a project management tool and (2) and issue tracking tool specifically for software teams.
Simply install them and you are go!

The tool features a extremely fast spreadsheet-like user interface that made us forget were were actually using an application in the browser.
Keyboard shortcuts make entering and editing information actually enjoyable.

Tight integration with email means your teammates can add comments to items simply by replying, and live notifications make sure everyone is in sync at all times.

Not necessarily a new thing, but did we mention how blazingly fast this app is? Continue reading “[Tool Review] – Opzi – Collaboration Platform Featuring a Wicked-Fast Interface”

Retrospective 46 – #Agile #Games and #Kanban Monsters



Compliance – Development Teams are Product-Oriented

“Compliance, as it turns out, is not quite as high a barrier to Agile as we thought. The second surprise has to do with the approach teams have developed to getting over or around that wall.” – Tom Grant

Many of the app dev teams that have been most successful at dealing with compliance are, as it turns out, acolytes of the product-oriented approach, asserts Tom Grant. They may not realize it, as their work output may not be any more productized than it was before. Instead, compliance is what turns into a product.

In hindsight, this approach makes perfect sense.

Products need anchor points in time, which compliance certainly imposes. Audits and regulatory submissions impose a deadline for a particular “release,” the package of documentation, aggressive risk management, accountability, and other requirements needed to get a stamp of approval. The definition of “done” is very clear in a way that a backlog of user stories might not always suggest.

Either You Are Compliant, Or You Are Not…

You try to negotiate with the stakeholders to help them understand that you may be satisfying their requirements, just not in the exact way they expected. The one difference, of course, is that you can’t cut anything from the release: Either you’re compliant, or you’re not.

So, what do you think?

[HT: ComputerWorld]

The Path to Product Success is Not a Straight Line

[Guest Post: Craig Strong, MBCS CSM has been involved with software production for over 12 years and is currently  contracting as a ScrumMaster for Sky. Having been a developer Craig has experienced first hand the effects and problems when being managed by various project management techniques and frameworks. On a daily basis Craig is responsible for managing,coaching and improving cross functional teams using Agile. Follow him on Twitter @craigstrong and blogs at]

Although I see this often, I am always amazed when people assume they precisely know the path of a project and want to stick to it until the very end, even if that’s in the distant future. Why do so many stakeholders and project managers get so caught up in sticking to the original plan at the cost of change. Let’s get this right people, change is good! It’s so good, it even says so in the infamous manifesto :

“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.” – Agile Manifesto

Although it’s safe to presume that everyone using Agile pretty much knows the above, is it understood and practiced well? You can carry out all the facets of Agile development and still not be “Agile” as a business. I often hear comments such as, “what about features ABC which are in the backlog, we still need those right. Thats what we agreed to in the original plan, you must deliver it!”. The answer of course may very well be yes you may need both, or maybe not. Just because it was set in the original requirements, is that enough to assure its value.

The key component of change is value!

A core concept of Agile development is the ability to change direction often and when needed with the use of discovery exercises such as the sprint review. Feedback can come from anywhere, from market analysis, the teams building the solution or customers. Such changes are made when new requirements are discovered and those changes have more value than other items remaining in the product backlog. All we need to do is order them by value, factoring the remaining time. Simple right?

It seems in many other different areas in life, change is carried out and never questioned. Anyone driving to the office each morning will know this. Whilst driving, one is constantly watching the road, other vehicles, the weather and their own vehicles performance amongst many other things, looking for changes to react to very quickly. If an obstacle occurs such as road works, the driver alters course to the destination. What the driver has done, is evaluated and concluded that there is more value in changing the path. In some cases could have even changed their path to avoid a catastrophe. Yes the finish line in this metaphor is the fixed destination being ‘the office’, but the journey to get there is not always constant as with almost everything in life. Even Barack Obama stated the risk of such in his presidential campaign :

“I don’t care whether you’re driving a hybrid or an SUV. If you’re headed for a cliff, you have to change direction.” – Barack Obama

Why isn’t this so easy in reality?

Well aside from the fact that old habits die hard, the inbred thinking of traditional linear product based projects, wrongly assume that the most efficient way to get form point A to B in projects is a straight line.

This is particularly the case within software industry.

Most projects are planned this way, an example being waterfall projects which are straight lines that are staggered through Gantt charts. In reality point B is in fact value and as soon as you start your journey from point A, the value could have changed from point B to point C. Therefore fixing the path to a products destination through a straight line will devalue to the result or in extreme cases kill projects. Don’t assume that the original product specification is fixed. Expecting to deal with change often, will ensure that value is the focus, not the original plan itself. If businesses stick to their business plans to the letter in favour over responding to the market, customers and competitors, that is a plan to fail. Being Agile is having the ability and knowledge to change and using it when necessary.

Agile Innovation Games

We here at AgileScout love Innovation Games. We’re all about making work more exciting, engaging, and worthwhile to everyone involved. Work doesn’t have to be a drag. We’ve covered a couple topics on this before:

Thanks to Luke Hohmann we’ve been resourced with some of the top games. We decided to drop them here for all you Agile coaches to utilize. Have fun! Continue reading “Agile Innovation Games”

Monsters Built Using Kanban

I am not a big Facebook fan (although Zuckerberg is very Agile). Nor am I a big online gaming fan (though Warcraft seems like tons of fun).

What I am interested in are all things Agile. It seems like one of the most popular Facebook games out there has been built utilizing Kanban. Now that’s something worth reading about.

According to Wooga Product Lead Stephanie Kaiser, the development team has fully embraced some Agile principles:

Short Release Cycles

They work in weekly release cycles using a mixture (or, as they say: the best) of Kanban and Scrum. Every Tuesday they release a new version of the game on Facebook. The next development cycle begins on Tuesday and continues until that Friday. Over the weekend they refresh our minds and prepare to fix the bugs found in the new version that Monday.

“These short release cycles are tough, and every team member must work in a very disciplined manner to avoid delays caused by inter-team dependencies… But it pays off. We move fast, but we are still flexible enough to change priorities on a daily basis. Once a feature is finished, we usually release it while still maintaining the weekly cycle on top of that. Therefore, if someone in the team has an idea (or a finding of a usability test) today, it can be included in the next version—if its priority is high enough. In my experience, this direct impact on a game really motivates everyone on the team.” – Stephanie Kaiser

The Team

wooga is organized into dedicated game teams, with one product lead. All team members—developers, graphic designers, project managers and additional product managers—are dedicated resources that work on just one game. Each team has an individual office room which establishes a concentrated working environment with very short communication distances.

Continuous Testing Throughout

Usability testing

From the very beginning of the development they invite people outside of our project teams to participate in usability tests at wooga.

“My first test on Monster World was done on a paper prototype, with a pen, which served as a mouse. I showed the prototype to possible users and asked them to use the pen and “click” as if it were a computer screen. The page behind the click would be the next step in the user flow and was also prepared as a paper prototype. By testing early and often, we tried to avoid conceptual mistakes at a very early stage, before we even began development.”

They test our games every two weeks and Product staff is always in attendance. Right after a test the “watchers” immediately discuss their findings and decide upon priorities for the next development cycle. They also regularly invite everyone from the team to join a test. For developers and graphic people in particular, those sessions give a very deep insight into the world of user behavior.

Sounds like a winning combination to me.

  • Short release cycles
  • Dedicated teams
  • Continuous testing

[HT: Inside Social Games]

Retrospective 45 – England Prevails + #Free Book


Book Giveaway – Execution – The Discipline of Getting Things Done

Execution: The Discipline of Getting Things Done

This is a part of our yearly giveaway series!

How to enter:

  1. Comment on this post
  2. Tweet this post

Simple. Jump on it! Contest entry closes (for this month) on August 19, 11:59PM.

Last Month’s Giveaway: Making Ideas Happen: Overcoming the Obstacles Between Vision and Reality – Scott Belsky

Best Tool to Manage Distributed Agile Teams?

[We review Agile tools, have you seen our Agile tools list?]

Surveys are fun, but you have to look at them with a keen eye. Sometimes the results skew towards certain biases. This exact thing happened when the Ainstainer group put together a poll for the best tool to manage distributed Agile teams.

Some definition to begin:

  1. A Remote Team is a team of software developers that are located in an other city/region/country
  2. A Distributed Team (as defined by Ainstainer) is a team with members that are located in different places
  3. The main difference between these two teams is that distributed team is multidirectional (at least 2 or more locations),  while the members of a remote team are usually placed in one office with the Product Owner in another area (country).

As for the Poll Questions:

  1. What is the best Agile Tool for managing distributed teams?
  2. What is your experience in using the chosen Agile Tool?
  3. What country do you represent?

We love Canada. They have a bunch of pride. Out of 68 respondents from 17 different countries, 58% were from Canada… and guess what tool they said was the best? A Canadian Agile tool: Urban Turtle. Go figure, right?

Find the poll results [here].

Agree with these results?

What are your favorite tools for managing distributed teams?

Let us know in the comments.

[HT: Ainstainer]

Agile Pathfinder Program – Free Agile Schooling (UK Public Companies Only)!

Agile Pathfinder Program (APP)

Public sector user group Socitm is launching a programme to test agile methodologies in IT projects for local government.

Agile approaches are designed to enable projects to become more flexible, responsive to change and innovative.

The program follows the government’s acceptance of recommendations made by the Institute for Government to implement a new approach to IT projects, following its bad track record of project failure.

The body for public sector IT professionals is seeking four to six volunteer organisations with suitable projects to create an Agile Pathfinder Program (APP) starting September 2011, so jump on it!

APP will be managed through a collaboration between Socitm Insight and IndigoBlue Consulting.
The program aims to understand the value of Agile, how it fits with current business change, the best ways to test the Agile methodology, and how best to promote the adoption of agile in a wider range of future IT-enabled programs.
“Agile could lead to a better, more focused approach to IT investment in local government.” – Martin Greenwood, Program Manager at Socitm on the program’s ability to give councils the opportunity to learn together about a beneficial methodology.

Government and IT – “A Recipe for Rip-Offs”

We write a lot about what the government is doing with Agile, especially the UK. With DSDM in it’s back pocket, and Agile methods taught to University students, it would make sense that Agile-reform will take over and help businesses succeed. But that doesn’t mean they have always worked in the past…

[Read it here]

The Public Administration Committee of the Parliament of the UK recently posted a scathing report about how the UK government has done in regards to IT work. Call it a report card for the UK Government and IT. The published report was ordered by the House of Commons to be printed 18 July 2011. It’s definitely worth a read… if you need something to put you to sleep tonight. But I like to read this stuff because that’s what I love to do. 🙂

Essentially the government is: dumb, pays more for IT work than anyone else, wastes money, and allows IT contractors to sell them $100 paper clips…


The IfG identified three main barriers to using agile working methods in Government:

  • Governance issues. The current approval process looks for a detailed specification as a sign that a project has been properly thought out, but such specifications are not normally produced for Agile development as the specification is expected to change as the project develops;
  • Commercial processes. A preference for fixed price contracts to deliver a particular solution reinforces the tendency for both sides to demand a high level of detail up-front;
  • Cultural issues. A reluctance to delegate and assign high levels of responsibility at lower levels of the organisation, in addition to a more general wariness of change from inside Government.

Continue reading “Government and IT – “A Recipe for Rip-Offs””

Can Agile Software Development Deliver a Great User Experience?

Niki Dare from Asynchrony Solutions recently wrote an article about the possibility of just-in-time Agile development and design. Can Agile development, with all it’s quick deployment times, create a user experience that is not only good, but considered “great” for the user? Many people have offered up opinions, including taking advantage of Iteration zero and infusing each story or task with user-centered design principles. But the big dilemma still remains. How much upfront design and usability is too much to be considered Agile?

“As a designer, I have been fortunate enough to be a member of several development teams that each followed their own unique process. Although what works well for one team doesn’t necessarily suit another team’s needs, the principle of integrating just enough user-centered design can be applied successfully within almost any agile development project…” – Niki Dare

Pre-Iteration Planning

Truly embracing Iteration zero, Niki has found pre-iteration planning to be extremely effective. This tactic works great if you have a client that knows what they want about a week in advance and is willing to mostly stay committed. Essentially the user experience team works an iteration ahead of the development team. A short pre-iteration planning meeting is had with the client to determine their upcoming needs for the next iteration. This method is most successful when there is an overall understanding of the application and its functions that is agreed upon. 

Minimum Marketable Features

The idea here is that a succinct set of tasks are identified as a minimum marketable feature. This feature, that should take no more than a couple of months to complete, is then well-defined and understood by the user experience and development teams. Similar to using iteration zero, it is best to allow the user experience group to be a feature ahead of the development team. For the first feature it may be helpful to start with something that is development heavy.

Formative Testing and User Experience Testing

Validating any new additions to the system, this type of testing is very beneficial to maintaining a good user experience. The most effective method is moderated testing conducted on-site so that the users can be observed directly and probed for as much insight as possible.

The best thing to do is to conduct usability tests on individual processes or tasks in the system and then act immediately on the findings. Try to keep the scope of the test as narrow as possible so scripting the test is quick and too many development tasks don’t result from the testing.

The Danger of Only Doing Just-In-Time-Design

The Agile development process boasts doing activities just-in-time to mitigate waste and allow for requirements to change even while code is being written. Just-in-time design can work in cases where a high-level design or concept has been created and approved.

But doing true just-in-time design can run the risk of losing sight of the big picture and creating a disjointed user experience or having to rework previously developed screens when new ones are added.

Interestingly enough, Niki has decided that a user experience team should be different from development, unlike Zuckerberg’s Facebook development teams, where the developers are the UI/UX. All of her suggestions point to a design-grooming of sorts ahead of the team. All this sounds good to me!

[HT: ITWorld]

Retrospective 44 – #Agile Requirements and Org Structure


Algorithmically Estimating Developer Time

Vic Cherubini recently came up with an interesting way of calculating developer estimates that get more accurate over time. When I began reading it, I simply said to myself: “Well if you estimate over time… the averages should just come out in the wash anyway…” This could be true or not, what is interesting about Vic’s system is that per the algorithm, you should improve over time.

  1. Set up an Issue Tracker – Something to contain your issues/stories/etc like a developer backlog.
  2. Give points to issues – Fibonacci or doubles works here. Points should be integers greater than 0. The point system is entirely arbitrary, but points should be relative to how hard the issue is to the other issues in the project.
  3. Estimate total number of hours to complete each issue -Based on personal experience to start
  4. Complete each issue – Track total amount of time it took to complete. This does not include waiting around for the client, or sitting in meetings, or doing other necessary administrative work. This is simply an algorithm for when you’re actually coding, architecting, or otherwise engineering what the issue specifically asks for.
  5. Reflection – Calculate your efficiency ratio, or ER. The ER is the ratio of the number of hours estimated to the actual number of hours taken. This needs to be calculated for each issue. Next, multiply the ER by the point value of the issue. I call this the developer effectiveness, or DE. Ideally, your ER will be close to 1 and the two values will be approximately equal.
  6. Summary – At the end of the project, developers who are good at estimating their time have a sum(DE) >= sum(possible_points). Note: The possible_points variable is only the sum of the points for issues that developer worked on. Developers who are not as good at estimating their time would have a ER less than 1, and a sum(DE) < sum(possible_points).

Over time, you will be able to track your effectiveness at estimating time. Thus, if your ER approaches 0.5, you might think about doubling your time estimates for future tasks. Alternatively, if it approaches 2.0, perhaps shave some time off the estimates.

What are your thoughts? Make sense?

[HT: LeftNode]

Agile Hearts Lean Startups

At the forefront of the lean startup movement is Eric Ries, the creator of the Lean Startup methodology and the author of the popular entrepreneurship blog Startup Lessons Learned. At the San Francisco conference recently, Ries made a clarion call for wiping away our previous conceptions about startup businesses [Video below]:

Watch live video from Startup Lessons Learned on

“I think right now we are wasting peoples time on an industrial scale.. we are building companies that fundamentally have no customers.  We are building products that get pulled off the shelves a few weeks after they are launched, after years of R&D…  Even the companies that are supposed success stories, the ones that get bought — how many are really living up to their potential, the time talent … energy determination and creativity that was poured into them by their founders and employees.”

The lean startup concept, which has its roots in the software industry, is based on the lean manufacturing philosophy of producing value faster, better and cheaper through continuous, documented improvement. It also borrows from the principles of Agile software development, based on constant interaction with end-users as software is designed and built.

In a traditional startup company, a product is conceived and built, and maybe months or years later is rolled out the door. Lean startups work in tandem with customers to design and build products through a series of rapid prototypes and iterations… yes, very Agile indeed.

You can learn a lot from the startup world. My suggestion is to take a look at not only lean startups, but take a look at Eric’s blog on it as well.

[HT: SmartPlanet]

No Organizational Charts in Agile?

Most companies use a traditional pyramidal structure, i.e. boss at the top, next in command on the line below, their underlings on the next level. John McKee asserts that this structure probably started about 5,000 BC with the Sumerian civilization. After they crashed, it was picked up by subsequent generations of leaders — next being the Egyptians about 2,000 BC. It has existed, more or less, in the same style since then.

Given how successful this reporting and management structure was for all the past civilizations, I am not inclined to recommend it to anyone.

There are tons of management studies that support the reasons for not using a structure like this. Key issues include

  1. They are always out of date
  2. They don’t deal with how things “really” get done
  3. They distance company leadership from the important work of the organization


They work when the boss is involved. And, if he or she isn’t involved, they show that the leader is not up to the task and should be replaced.

It’s not simply for small companies. The critical factor — that the boss is never more than one step away from the person who’s doing things – can be modified for even the biggest companies.

Flat organizations work because

  1. Decisions are made faster
  2. Money is spent according to the priorities of the company
  3. There’s less culture clash internally with fiefdoms being created by each department head

Agile or not? Do org charts have their place?

[HT: Tech Republic]