Tuesday, July 29, 2014

Inverted Management Structure and Agile Practices

Inverted Management Pyramid
Fig 1

The Inverted Management Pyramid
The Inverted Management Pyramid (IMP) is a reversal of traditional management styles.  In this style non-supervisory roles, those closest to customers or production processes are placed at the top of the pyramid(Fig 1).
  Each level supports the level above, by trusting and enabling the level immediately above to accomplish the organizations goals.


Agile Software Development
Part of the core of Agile practices is the idea that smaller feedback loops result in decreased development time/costs and/or software that more accurately meets the businesses needs.  This is due to increased communications between the development team and the line of business, often mediated by a role called the Business Analyst.  In this sense the development team almost operates autonomously.


How they work together?
If the development team is nearly autonomous by working directly with the line of business, then what is the function of management?  I have heard that it is a common scenario of IT shops that adopt Agile practices that those in management operate in a very chaotic fashion.  Referring back to the IMP, the role of management in an Agile shop is to ask this question to the level above "What do you need?".  On the Agile teams I've been involved with, the top-most role to ask this question is the Iteration Manager, but that should not be the only role asking that question.

Needs that can be solved by Management

  • Contracts - negotiations, authorization, etc
  • Financial - budget management
  • Human Resources - hiring, reviews, salary, etc
  • Escalations - work with management in the line of business to resolve issues to which the team is unable to resolve themselves

Monday, July 7, 2014

EventSourcing Example

After watching the "An Autobiography of a Reactive Application" video from ScalaDays 2014, I became very curious about EventSourcing and CQRS (Command Query Responsibility Segregation).  I find the EventSourcing pattern very interesting because my team and I almost used this pattern without actually knowing anything about the pattern beforehand.

EventSourcing does not store the current state of the app but instead keeps an "audit log" and reconstructs an object's current state from the log.

My quick and dirty sample: