In software engineering, refactoring a module of code means that you change its internal workings while leaving its external interfaces intact. A developer might do this to make the internal workings of their software simpler, more efficient, or easier to understand. The key is that refactored code maintains it's contract with the surrounding system. Everyone can still get what they need from the refactored system component in exactly the way they have always gotten it.
There is something here we can draw from as project managers. As we make the switch to agile project management, we must stay plugged in with the language of the organization. We need to maintain the contract the business has come to expect. Over time we may be able to influence how our organizations think about project management best practice. At some point we may even be able to renegotiate the contract.
For now, we need to take what we know about adaptive and traditional project management and establish a framework for delivering in the language of the business. The PMI process groups and knowledge areas provide a well thought out and disciplined foundation on which to build. Our challenge is to approach the discipline of project management with an agile mindset. To figure out how to leverage agile practices within the constructs of the accepted project management best practices.
Over my next few posts we'll break down the PMI process groups, knowledge areas, and processes to explore how we can build an effective agile framework using the established contracts. If you are interested in a little pre-reading, check out the following posts from my blog and a few others:
Subscribe to Leading Agile
No comments:
Post a Comment