Requisite Agility (RA) is an evolution of Requisite Organization (RO) adapted to the complexity of a global connected world.
The common denominator of both RA and RO is the initial problem that RO tried to solve like “lack of effectiveness of bureaucracy within a stratified hierarchical organization” (Wikipedia) including specialization of function.
Function control is related to scientific management, assuming that patterns are preceding data. Agile, on the other hand, is “Sense-Making” where you are looking to situate a network and where data precedes framework.
They are several points that don’t make any sense in “Sense-Making/Agile”, like management or accountability because of the self-managing nature of that complex system.
Organizations like SAP or Daimler are looking about the Stern Steward model applied under cover of “digital transformation”. That model is appealing “Sense-Making”. They are using the multiple sides platforms model with three principal layers like platform (mid and long term programs), swarms (short term projects) and plexus (Governance). In my eyes, there is no clear “agile” concept responding to that new challenge that companies are already testing. There is, maybe, where RA has a role to play.
Create meaning not tools
I don’t think that RA will come out with a set of processes and methodologies on RA because it is off the grid or maybe we all have our methods and processes. What matters is, like Kasmir mentioned in one of our meetings, that strategy and Northlight will be incorporated again at C level and not outsourced to a tiers. It is all about engaged C Suite and not bureaucratic management.
Why Requisite Agility is different that Requisite Organization?
I believe that RO is totally command-and-control and perfectly designed for the industries of the 1950s.
At that time, demand was more significant than the offer. People operated in a complicated Sense/Analyse/Respond relationship even if science demonstrated that that model doesn’t work for over 20 years.”Cognitive capability and social, emotional maturity of employees” is an odd sentence, but I give you hear how things happen in CAS.
In agile or responsive systems (CAS), you are building a system allowing emergent behaviour, and we are using “Flocking behaviour” as “process” to create the dynamics in that system. “Flocking behaviour” can also be understood by “organic growth”, it is based on Boids research and applied since the 1960s. In Flocking, you care about alignment, dynamics, avoid collision, focus and separation (https://medium.com/@pierreneis/when-if-agile-is-nothing-more-than-the-dynamic-of-a-system-8c8d02db3de1).
Once you understand Flocking behaviour, you see that:
Agile is the challenge and not requisite. An agile organization is flat, and non-agile is a segregate monolith shaped for robustness designed a long time ago.
In our preparation meetings, we came to the point to add “O” to VUCA. We went to the idea that an organization is in continual evolution, and RA tries to address governance issues on that move.
Because my all have different ways to address that complexity, we already designed the first version of RA to link our various initiatives without interfering between our believes. During our last three meetings, we experimented what RA might be. Now we roll out to test it during the coming Unsymposium.
As an agile coach, it is completely boring to be considered as an evangelist or whatever guru. This is perhaps a mark of respect and that’s fine but when you are working daily with teams this becomes weird while trying to help, and people just see you as another “Moses” and not as a helper.
Every year new agile coaches are emerging and they are doing the same that I and some of my friends did a decade to 20 years ago. Genuinely this is okay, it is like when your 5 years old child is showing up its drawing. You are amazed by this mix of curves and stripes because you acknowledge the effort. But in fact, you have to admit that your child isn’t that great artist. That’s all to say that every years new people are coming with the same ideas, the same old ideas and even hijack the early sense of a concept without improving the early concept or worse transform very tiny subparts and develop their thoughts like a syllogism. So let´s try something new.
In 2011, I attended the seminar of Leading in Complexity by Dave Snowden in Frankfurt(Germany) and it was a blast for me. The explanation of the Cynefin framework helped me to understand how systems are behaving and how to act on it. Much later, in a very passionate conversation on LinkedIn this year, I discover that my understanding is a bit different from the average mass of Snowden´s fan, maybe I´m wrong but I want to explain how different it is.
Most of my colleagues are using Cynefin like a static measure to understand how a system is. The problem, this is an assumption, this is an observation from somebody outside of that system. You have to know that every observer is impacting the system and the only choice you have is to be part of that system.
What is happening in the system from the Cynefin perspective?
On the boarders of the Cynefin diagram, you can see links and dots. The dots are related to the agents in the system (can be a bunch of things, but in my case, it will be people). The links are representing how the interaction of those dots (people) is in a particular domain:
Complex: the 3 “people” on the base are interacting together and the one on the top doesn´t.
Complicated: all people are linked
Simple: only a top-down link exist
Chaos: none of them are linked.
Since 2011, I considered the yellow dot like the representation of leader or manager or authority, and the black ones like “team members”.
Then I translate the Cynefin model a slightly differently:
Complex: the “team members” are autonomously interacting together and co-create together a new “emerging” solution. Ex. building on the top of each one’s idea.
Complicated: all participants are interacting together to analyse something in order to collect “good practices” or to validate an outcome.
Simple: the information shared from the “top” is obvious for all participants in the system and doesn´t need to be discussed. Ex. Fire alarm = get out.
Chaos: nobody is interacting, all the people are working in their own area.
credits Dave Snowden, Cognitive Edge
This learning loop was for me a second blast even I do not fully agree on that picture. My pain point is on the crossing of “Disorder”, the black hole in the middle. “Disorder” is the unknown and is like the “0” in numbers, it helps to define “Chaos” and another form of dynamics and not as an unknown form. I don’t like it because it gives credit to take actions in a system which we have no data (unknown). A bit contradictory but I’m pretty sure there is a perfect answer on that.
Anyway, from my first interpretation and while using the Learning representation, I started to design a facilitation process called PLöRK. This model works like that:
Start at Simple: The purpose of the workshop, of the learning point has to be obvious for all attendees. The invitation has to be crystal clear to ensure where do we want to go with our learning.
During a couple of minutes, each attendee has to think individually what and how the purpose resonates. That´s my Chaos.
After that time-box, you ask the crowd to work together to solve that learning problem. This is also time-boxed and takes the majority of the time. (Complex)
Once the time is over, we all debrief together and some points are clarified, adjusted, improved (Good practice). Here comes my.
As the teacher, then I validate the “Good Practice” with “Best practice” and the result might be obvious for all attendees. Back to Simple.
This sounds easy. Once I made a train-the-trainer session in an insurance company because they wanted to know more about PLöRK. The first 2 stages worked well and I brought the crowd into Complex. Then I saw that one member was answering emails on his Mobile Phone. I waited until the student was finished and told to the crowd that I have forgotten something. Pulled them out of Complex to Complicated. Explained again the goal of that exercise, ensured that all phones are moved away, and relaunch the loop with better results.
credits Pierre Neis
Here is the model. If we take a scrum as example, it looks like this:
scrum starts with a vision (simple) or a sprint goal. That goal is not deterministic, it is a forecast, an expected goal.
then during the sprint planning phase, each of the team members try to show up what is this all about. (Chaos)
then the team, collectively try to design what and how the solution might be (Complex)
the team discuss negotiate with the Product Owner and try to make a dealon what has the highest business value and lowest complexity, or what needs to be fixed now (Complicated).
then the improved sprint goal is agreed (Simple) and the team starts their sprint (Chaos) until next days daily scrum where to team aligns and works together until the end of the sprint (Complex).
the sprint ends in a Review (Complicated) and a Retrospective(Complicated) and a potentially shippable increment is marked “done” and the working model has been improved according to good practice (deviation from the initial working model) for Simple.
then the loop is starting again.
So, let´s assume that you agree with my demonstration. What happens if someone ask a team member during the sprint to do something not aligned with the sprint goal? What happens if someone interrupts the sprint like a manager making an unplanned All-hands meeting? or having a visiting agile coach?
It happens like my student answering email during my class. The dynamic is broken and you have to relaunch the loop.
To ensure the adequate dynamic, the scrum master has to care about that. I say scrum master for that example, but it can be the Process Manager (in Kanban) or an Agile coach. The responsibility for those roles are huge because they have to care about the system created by the team. They are part of the team and protect the system from external threats. They can’t be an authority (yellow dot), in fact no one in the system is an authority and it is managed on its own (self management principle).
In my example, I used scrum to tell a story about agile system dynamics. I believe that scrum brings the minimal organisational setup with just enough roles to ensure a great dynamic with less “authority” impact.
At the early stages of agile, a team is on its way to complex adaptive system behaviour but cannot fulfil the expectation of a complex adaptive system due to the strong result oriented context. In parallel, R&D tracks are working in a fully complex mode with the only constraint to show up monthly their findings like below (complex-complicated-complex dynamic in fact):
credits Pierre Neis
The Cynefin model isn´t enough to understand agile systems dynamics. The core principle is to build a system allowing “agile behaviour” and that behaviour is emergent (empirical) this means that the system learns by itself while experimenting (praxis) and discovering his own abilities allowing to modify its boundaries: tight enough to see its limits, large enough to have the freedom to progress. If you know D. Snowden´s metaphor on the 8th child birthday party, here I have to consider all the birthday parties of a growing child (this is the purpose of retrospective in scrum).
credits Pierre Neis
By adding Flocking behaviour theory with the Cynefin model, then your scrum looks again a bit more different and interesting:
scrum starts with a vision (simple) → alignment of the agents (stakeholders, design alliance, design the system)
then during the sprint planning (Chaos) → self commitment
then the team, collectively try to design what and how the solution might be (Complex) → cohesion of the agents (stakeholders) ensures complex behaviour
the team discuss negotiate with the Product Owner and try to make a deal (not imposing) on what has the highest business value and lowest complexity, or what needs to be fixed now (Complicated)→ alignment.
then the improved sprint goal is agreed (Simple) and the team starts their sprint (Chaos) until next days daily scrum where to team aligns and works together until the end of the sprint (Complex)→ alignment + cohesion
the sprint ends in a Review (Complicated) and a Retrospective (Complicated) and a potentially shippable increment is marked “done” and the working model has been improved according to good practice (deviation from the initial working model) for Simple→ separation
then the loop is starting again.
I agree that this can be an obscure explanation but I will sum it like this:
credits Pierre Neis
Simples rules applied to scrum and agile:
point to the destination: goal, roadmap, true north, vision
avoid collision: scrum-of-scrums, impediment bashing, daily stand up
How does scrum looks alike when applying Agile Systems Dynamics then?
You take the basic rules defined in the scrum guide and improve it with these 9 principles:
Scrum X, core principleScrum X, set the stageScrum X, everything is not an optionScrum X, DecideScrum X, no never ending storiesScrum X, human relationsScrum X, balance is everythingScrum X, what do you realy want?Scrum X, set the pace
Now, you have all the tools to move on into agile and take care about:
Scrum X, from mechanic to dynamic
As conclusion, I didn’t addressed how to build a system in this post and nor what a system is. One think for you to take into account, that system works when decisions are taking into the system and not outside-in. If you are a scrum practitioner and your Product Owner isn’t part of the team. he or she is not in the system.
Sitting in front on my computer and writing these lines let emerge in me an angel and devil fight. Should I push forward everything that doesn’t work or should I explain what works? What if people are feeling injured by these words? What if my customers are feeling offended by these lines? What if people are misinterpreting this post like a revolutionary manifesto? What if I lose most of my contracts?
Or…
Is it important to share my experience with fellows trying to balance with what they feel and what they feel? Usually, the feeling is that agile is feasible and the fact is that is terribly complicated… or not.
So here my humble insights coming from lots of problem-solving experiments with teams of developers, managers and leaders mostly in large banks but also with SAP S.E. I thank all these people for their trust and their passion on this challenge.
How everything usually begins?
Like everything, you start with a proposal, a first draft to explain how we might proceed:
the initial toolbox
This is an “appetizer”, this is the ideal world… when you know nothing about the context, the culture, the maturity and the “gremlins” or other “toxins”. This the picture of the CV, the certification paper that opens the door so that someone at your customer side cannot say that you don´t know your job.
Besides the toolbox and because you are a professional, you have to provide a timeline to estimate how much you will cost:
the magic roadmap
Even if in a bird view, this is about investing in a better future, most of the managers are cost killers but this is part of the game.
Even if this is mostly false because it is an assumption, I made myself a review of that roadmap (real one) two years later:
Review of the initial roadmap after 2 years
Distill Agile Mindset was “so so”, this means that you are still struggling with the simple agile ideas like self-management and prioritization. Why? There is magic here or people believing that once you have one or more agile coaches in your enterprise the job (agile mindset) is done. Hmm… It is acceptable that our clients need time to change, but I have to be honest by writing that human nature is what it is and most of the hints came from other agile coaches, or managers hiring other coaches, or “nominated” agile coaches and Head of agile without any experience of agility other than having once hired a scrum master, have watched something about agile on YouTube… Anyway, this is the part of change management that I don´t want to explain today.
Scrum was “so so”. Scrum was chosen as main framework and that’s fine. (Even if you believe in the magic of SAFe or LESS, you have to set up Scrum for the first 2 years). Framework has been considered as a “chocolate box” this means that if you are picking all the white chocolate and leave the black one, you are considering doing scrum. That’s totally wrong! It took a while to explain that scrum is a minimalistic organizational model working as a scaffolding to create agile dynamics. It´s not “by the book”, or “100%”, it is all or nothing. This point was only the pic of the iceberg, the real problem was resource allocation (this is the name to let individual working in several teams, 10% on this, 20% on that, 40% of those, etc…). You get it, agile doesn´t work in matrix organizations. So so, because it took around 2 years to understand that work flows in a team so that demand is balanced with capacity, and not collecting as much demands as possible and then chasing for people (cheap people in fact) to start the work and never achieve it. That is known by everyone in the company and all projects or programs are magically completed at the end of each year by changing its name (no sarcasm).
Continuous Integration was “what?”. This was completely skip away because Build has a budget, Run has a budget, Data has a budget, Infrastructure has a budget, Operations is mostly offshore third parties and nobody cares about Business or Service Desk. Budget means has a manager. Budget also means “manager´s power”. This is a war that you will lose.
DevOps was “so so”. Ok, more so than so in fact and that due to the previous paragraph. In reality, even in the Phoenix Project is on most managers desk, DevOps has been completely “trolled”. DevOps means now that the developers have to ensure Service level 1 and 2 (support) in the context I explained in the Scrum paragraph before.
Ok! Even this sounds a bit depressing, we have to adapt to the context and some old habits are quite complicated to change in big global organizations. And in a second hand, this also no finger pointing but just the consequence of a lack of purpose and overwhelming bureaucracy leading to reproduce obsolete processes for ever.
What is the traditional way of managing projects?
old school wrong project management lifecycle
This is the roadmap:
Consulting & sales got a contract and a development agreement where both parts are trying to make a win. In reality, consulting & sales (c&r) are looking to get more in their “pipe” and expect to detect new opportunities for change (change requests) where they can charge to an higher price. (c&r) are selecting some project manager and introduce the contract to experts in order to create the first milestone of the contract: the blueprint. Ideally the blueprint consist of standard blocks. In reality, this is an opportunity to detect new “change requests” coming from experts and not from the client.
Blueprint is quite interactive and usually the customer and some of its representatives are active. When blueprint ends a huge part of the project budget is consumed. In digital projects, “blueprint” is called “customer journey”, different names, same nature, same effects, same outcomes. Once the blueprint has been validated by the customer, this one is handed over to another team: the development team.
Development. The development team is considered as a service provider and not a project team. The project manager hand over the blue print to the team. At this moment, all the experts and also the customer are no longer available for feedbacks. This is at this stage that usually people are remembering agile and are asking for help to ensure the delivery of what has been promised by tiers. The development team needs to understand rapidly what this is all about, usually no one is collocated, usually they are also working for one or two other project managers and some requests from different managers. After postponing the deadline one or two times, 70% of the development is ready for testing.
Testing. The development team is handing over the tests (usually not written) to one or two testers in India who also working on something else. The project plan needs to be shorten because of budgeting costs reduction (another corporate department). So instead of 2 months they have 3 weeks.
Delivery. The planned 3 weeks become 3 months and the project launch has again being postponed due to SOX Freeze, system unavailability. The project run over 300% of the budget, get close to one year overtime and the customer is just happy to get something done.
Note: indeed this a stereotype to explain what is coming now.
Lessons learned towards agile: agile is made for development only, that excludes the project set up, the blueprint, the testing and the delivery. That is just wrong regards project management, totally wrong regards scrum, and the only agility here is for c&s.
How should it looks like?
agile project management strategy for ERP & BPM
Contract are proceed as usual and one of the consultants might become Product Owner of that development. A scrum master is identified at the beginning and attend all the meetings to meet all stakeholders.
agile principle #1 : you plan it, you make it
The Product Owner and Scrum master are setting up the development team that is 100% dedicated to that project.
To avoid wasting time, the full Scrum team (PO+SM+Developers) are identifying with the customer and its users what the needs are:
agile principle #2: focus on customer and users
From that exercise, the team discover what the real needs are and the Product Owner is in charge to translate these needs into a vision.
agile principle #3: Product is not the voice of the customer. (S)he translates customers expectations into a vision. The customer has its own voice.
After 2 weeks, the team and they stakeholders gather during a Sprint Review and some options are shown and the customer decides what matters and choose one. The others are skipped away or destroyed.
agile principle #4: Requisite is waste
Then the team starts to develop with what they know and build on the top of it.
Every sprint end, the customer can come with change requests which be negotiated with the Product Owner ideally in front of the team.
How to work with experts?
Experts or SME are necessary but not at the project start. Due to their expertise biases, they will pull the project into the sole direction they know, their expertise. Genuinely it is not intentional.
SMEs are “floaters”, they are helping the team to gain certain knowledge. Their job is to transfer their knowledge to the team and coach it.
agile principle #5: cross-functional team members and SMEs as coach
Composition of a Scrum Team
Developing or integrating or configuring a business process has a particularity, it is addressing different customers for different purposes:
one customer for the end-to-end business process
several customers for the components addressed by that business process
The Scrum Team cannot be a Product or functional team, it is always an end-to-end process development team: that’s what needs to be developed right?
agile principle #6: all teams are end-to-end
end to end scrum team composition
One role has been added to that genuine scrum team ,the process owner.
If you are merging Product Owner and Process Owner you will lose your component customers. In this model, the Product Owner is in charge with both customers and build its development strategy based on components and process.
BPM, SAP agile delivery pace strategy
Components or features like in the figure beyond should be small enough to be completed during one sprint (max sprint length of 2 weeks) and end-to-end processes should be deliverable once a month.
End-to-end processes have to be decomposed from easy to complex so that the easiest can be release for customer testing as soon as possible. Then, like in product development, additional complexity can be added into the initial process in an incremental manner.
Product roadmap and development strategy recap
Sprints delivers PSI i.e. features
Releases delivers End-to-end processes incl. these features
focus is given to involve both customer and user since the beginning of the solution development.
Deliver standards from the easiest but most visible to the hardest.
Each release should be actionnable so that the users and customer can start a work around of the solution and provide feedback
Think about the integration of E2E processes.
Done means ready to deploy and fit to RUN.
Release phase is deliver standard and collect change and start custom
agile principle #7: The end-to-end (E2E) process is the outcome and not the input of a development process
Role of the Process Owner
develop
aka member of the Scrum Team
as a team member, the process owner is self managed and cross-functional.
perform acceptance test and/or facilitate user acceptance test workshop / Bootcamp
co-work
as a team mate, the Process Owner helps the team to reach the Sprint Goal also for works that are outside his/her comfort zone
equal
not an authority
all team members have the same hierarchical level within the Scrum team, that’s the rule of the Scrum Game
Challenges for the Process Owner
identify the User in a end-to-end (E2E)process and create the User Stories
update the product roadmap with the Product Owner
identify the User/Customer for E2E process
define the persona aka User Role
collect User Stories from the Users
update the Product Backlog with the Product Owner
ensure or write the tests cases
ensure that the E2E process is INVEST (independent, negotiable, valuable, estimable, sized to fit, testable)
ensure the integration of E2E processes in a single process
update the process
E2E is part of Release DoD
create the definition of done (DoD) of the E2E process and work with the Product Owner to update the Release DoD accordingly
E2E has to be drawn and visible to all stakeholders
make the process visible from all stakeholders
use visual management and facilitation techniques to enhance the product backlog
Last recommendations
The challenge is to organize teams end to end and remove the illusion of expertise away. Another point is that you have always 2 different customers with different expectations: one for the process, another for the components of it.
Mid January 2017, I attended an interview meetings with a customer of a Global player and I got an unusual exercise: how to arrange a facility to make it agile?
My first reaction was WTH is that and then roughly I told myself to play this game, and I liked it.
So what means agile for a facility?
After this interview, I needed serious feedback, so I shared this exercise on Facebook and got awesome feedback from my pairs. On one day, I’ve got around 40 feedbacks that I can categorise in this way (sorry, have to summarise the content):
Ask the team
“Don’t design. Let people explore, learn and adapt. Give them some time to find out their own setup, they wanna start with. Let them be adults and don’t parent them, just because the IBM guys asked you to … “
“how do you get the team to take ownership of their team area”
“Remember the “self-designing team workshop” – let them figure out their collab setup, their appropriate work environment, their learning style the same way. Encourage “moving around” instead of creating fixed desks as little territories. This exercise is either a joke or a good demonstration, why the large ones don’t really get it 😉 “
“Although teams can give individual preferences and to an extent collaboration agreements but the scrum master has to do some interior designing to manage conflict if and when it occurs E.g. Open floor plans vs Private offices vs somewhere in between”
“Don’t mix up prescribing detailed practices (acting like a parent) and growing from first principles. Room setups will hopefully only follow an in-depth elaboration l why such a team wants to collab at all. If this is not understood, better stick to where people are coming from. A coach or Scrum Master starting to design work spaces should go back and learn the basics”
“Didn’t prescribe any; talking about conflict resolution. Kurt’s answer is pretty good”
“The correct answer is probably the caves and the commons where everyone sits and does pair programming in the open common area in the middle but has private rooms for when the bosses are doing deals on the phone or the rock stars are coding AI algorithms and need to concentrate.”
Worthless
“This is why the term “Agile coach” is worthless. Your test is about creating a seating arrangement and defending it? Really? Sounds like something for an interior decorator. Better question: how do you get the team to take ownership of their team area react”
“Hey, we need to design the new space for the Viper Project. Who can do that?”
“Fine as an interview question. Interview questions are not for getting at an answer; rather they are for learning how someone thinks.”
Proposition
“I think the chairs should be located on top of the monitors and the project managers should live in the bathroom.”
“As long as I had my iPhone, living in the bathroom could work”
“Architecture the layout following the agile principles. E.g Onion layered and circle “
“My first reaction is to design the work area. My next reaction is, ask the team! Get them involved, ask them to design their own work area. I bet they’ll like it better if it’s theirs than if it’s imposed on them.”
“My answer would get those people in the room and have them design it. I would have to go by some sticky notes and sharpies and add that to the list. “
“Love this exercise! The answer would be quite telling.”
“There’s some interesting stuff to probe into that go beyond space design: “the core team is about 20 people”, the siloing of technical/”SME” roles before they’ve even started, and including executive sponsors on the team. Definitely ask the team to design their own space…but before that, ask them to *design their own team* before imposing all these roles on them.”
“Especially if you find out they are all remote”
“So my answer of: pile everything into the center of the room and say, “Team – your first assignment is to organize this space to maximize the effectiveness of your team.” And then watch what happens. And not let them break the safety and fire codes. “
“Before I would try to solve the problem, I would point to them there are severe inconsistencies and ambiguities with the problem itself:1) there are “bad overlaps” of traditional and Scrum roles: a) sponsors and PMS “
On the recruitment
As a discussion exercise, I find it interesting. As the business I would learn pretty quickly quite a bit about the prospective coach. “
“Questions of this type can be very useful in getting to know the candidate and the hiring manager.”
“Correct but I saw an interesting and intriguing approach to agile behavior”
“It is easy to look at this on the surface and feel like the organization/person/people that designed this question do not understand Agile’s values and principles but maybe they are really looking to see how you understand the same by how you address”
“Isn’t that in a sense the great thing about this exercise. Everybody trying to design the room without group involvement misses the point of having an agile coach. But wouldn’t everybody who just say they would ask the team without on how they facilitate this discussion, be an ineffective coach too?”
“Hmm interesting guesses here. Now let’s assume that you have to Organise a stage for a project and you can have on site customers i.e. Not only developers. So here build a safe to fail Container facilitating the conversation.”
“I think it provides the hiring party with some great insight into the reasoning of the agile coach. Looking forward to your picture!”
This was a very interesting feedback from my fellow agile coaches and I would thank for their contribution: Michael Leber, Kurt Häusler, Daniel Markham, Atif Rahman, Amr Elssamadisy, John Miller, Djebar Hammouche, Howard Sublett, Pierre Hervouet, Linda M. Cook, Alan Dayley, Bob Sarni, Ralf Kruse, Astrid Claessen, Richard Kasperowski, Stacia Heimgartner, Jeff Lopez-Stuit, Alberto Brandoloni, JB Rainsberger, Michael Feathers, Griffin Jones, Mike Beedle, Dov Tsal. Guys you are awesome and I value all your comments… all.
AGILE4HR IS AN ON-GOING RESEARCH PROJECT WITH HR PEOPLE WITH THE INTENTION TO GET THE ANSWER ON 2 QUESTIONS:
is Agile HR?
how can we create HR Agile
In the economic context of a company, wealth is created by :
business value
knowledge value
optimal utilisation of inner resources including people.
HAPPY AT WORK?
Being happy at work doesn’t mean being lazy at work, it means working better, more efficiently and to be able to answer this simple question: what kind of value do you create when just doing your job? What kind of value can you create if you are fighting to survive?
OPTIMISATION OF RESOURCES?
Optimisation of resources means to create an environment where new ideas can be safely tested in a continuous flow of intrinsic innovation.
During the last decade, we learnt from agile and lean that people involvement increase business agility and reduce the response to risk. We tested this in the area of IT now it’s time to involve the whole structure.
The evolution of agile moved practitioners from engineering to organisational design and change management where « human interactions » is key.
Instead fighting against HR, shouldn’t we work together? Shouldn’t we hack HR with them to enable a human centric pivot?
AGILE4HR IS A COLLABORATIVE INITIATIVE MOSTLY HANDLED BY HR PEOPLE WITH THE PURPOSE TO BUILD AGILE ORGANISATIONS CULTURE.
Like in an agile project, this initiative is iterative, empirical and collaborative.
One year later, 10 countries and cultures later, we discovered common patterns for HR and redefine the traditional IT related relations of Agile Coaches to an enlarged organisational-based role. Consequence of this is that HR doesn’t stand for Human Resources anymore but for Human Relations.
TO REFINE THE SCOPE ALL TOGETHER WE USE CONFERENCES AND WORKSHOPS IN A SOCIALISING AND INTERACTIVE MANNER.
The presentations will explain the vision of this initiative and the cultural differences we faced during our workshops, trainings and meet’ups.
In the context of a conference, we will explain 3 steps:
Step 1: from Agile Coach point of view,
how we interfere with organisation transformation, how our roles are operational by coaching people, teams, creating a good morale, creating a sustainable pace, collecting lessons learned and manage on-demand efficient trainings. How we change the corporate culture.
Step 2: from the perspective of HR,
how recruitment can be managed, how corporate social responsibility can be managed, how to manage diversity, how to retain high qualified people, how to share the bad news, what’s about personal appraisal, etc.…
Step 3: Unleashed from surviving,
work has evolved to something that matters to people. Sense making is one of the drivers in the future of work evolution. Organisations will attract their people with their corporate values: corporate social responsibility i.e. agile will be one of the principal criteria.
Potentially Outcome: the Book
Once a year, we will document our community work through the publication of a book increment.
the agile agency 
You must be logged in to post a comment.