Tuesday, October 17, 2017

Checking Your #Scrum Team Health

Sunday, October 15, 2017

Working #agile with Russia

What is values based retrospective?

The exercise is an opportunity not only to get a common understanding of the Scrum Values and evaluate how the team adheres to them but also to dig a little deeper in the context of transparency, inspection and adaptation - the three pillars of Scrum.

Thursday, October 12, 2017

Working #Agile with Poland

Working #Agile in Vietnam

Let's review the basic cultural literacy about Vietnam in a working environment (#agile one ).

Working #agile with Romanian teams

Some companies choose ‘distributed software development’ where part of the team is in one location and another part of the team is in another country , this time in Romania. How is it ? 

Wednesday, October 11, 2017

Working with Taiwan (IT & #Agile)

Some of the key concepts to bear in mind when doing business with Taiwan.

Sunday, October 8, 2017

The Small Batches magic -Building Big one Piece at a Time

It is better to do work in small batches than big leaps -  guiding principle for how to do effective and efficient system development. The small batches principle comes from the DevOps community, where you do take a broader look at how to quickly develop & deploy software to users. Reducing waste, encouraging experimentation, and making everyone happy. Once you do small batches, agility, speed, and quality follows.

Tuesday, September 26, 2017

How to Implement an Agile Mindset?

A good processes can be destroyed when mindsets aren’t developed, let alone sustained. The rules of the 'Agile' game are easy to understand . The hard part is understanding why it works and how to make it work. If you implement only the right side of the Agile Manifesto you’ll be having a very hard time making it work. More important than the rules and roles  is the spirit and the mindset of Agile .


Monday, September 25, 2017

What is the role of a DevOps coach? Part 1(4) : What is #DevOps ?

By : Liat Palace  (Director, Delivery Technology Office Agile/DevOps Coaching Team Lead – Amdocs)  & Shirly Ronen Harel (Co-Founder & Agile / DevOps Coach -WeChange)
The first major issue we encounter when we start implementing DevOps is the need to gain a basic understanding of what DevOps is and what it brings.
I’ve been asked many times: Is it something that will disappear after a while? Why is it so important and why is it different?

Our friend Thomas Cagley @TCagley, in his article DevOps Primer: Definition, states that if you ask 20 people the definition of DevOps, you will get 12 different definitions and 10 people who are not familiar with the term. 

He then quotes David Herron, who provided a simple definition: “(DevOps is)…an integrated approach to software delivery that include process, tools, technology, resources.”"
For a long time it was a world of size, and big organizations had a clear advantage over small ones, sometimes even a monopoly.

Now with the fast pace of changes in the market, the game has changed. The organizations that are fast enough to react to changes and stay relevant have the advantage.
In a fast moving environment, where speed is a necessity and quality is not negotiable, organizations need to find a way to move from ideation to delivery as fast as they can, with the highest quality.

Which actions should be taken to move towards adopting DevOps?

First we need to remove some barriers. There are barriers between Dev (that wants to change the code, and add to it) and Ops (that wants to keep everything stable). We need to break down and adjust the boundaries between the developers and the operations people, so that they work together. We want to deliver products with good quality and fast time to production, and at the same time create trust between these groups.

We then need to remove some more barriers. The whole ecosystem should speak the same language and move the organization towards the same goal.

Marketing, finance, HR, learning services, procurement, and legal should all change in order to support rapid delivery and the DevOps changes.

For example, we see situations where the finance budget plan is approved once a year, and cannot be aligned with the rapid changes the DevOps chain requires.

So we can add tools. We can add them everywhere, making sure that there is no break down on the way to production. Tools play an important role in building awareness of quality. We can create continuous integration for every line of code, continuous delivery for any functionality added and tested, health monitoring, better logs and more. 

But I’m afraid that tools are not enough. Why?
Because we need to know where to employ these tools. What is a valuable application of these tools? How do we determine this? We need to know our production line. We need to identify production line bottlenecks, understand and set up the right process. Imagine we are a chocolate factory - we can add cocoa but still not deliver chocolate if the mixer isn’t working properly.

Tools, processes and barriers are only a small part of it. Why? Because we need people to be part of DevOps adoption. And they need to have the right mindset to be able to deliver the right feedback.

Why? Because in a rapidly changing environment, we need people to give us feedback from every part of the production line, whenever needed. In this complex environment, issues arise, change and being develop differently throughout the production line. Therefore we need people to understand the DevOps mindset and raise flags, when necessary. We need to quickly identify problems and solutions. We can only do this when we have the right mindset, and when everyone is on board and knows what they need to do and why. In this complex environment we need all the different professional perspectives to be available to us for fast decision making. We need to know where to use our tools according to accurate feedback and recognized bottlenecks, what to change and why. Without the right people and mindset, we are limited in our ability to do so. To reach this state, everyone needs to work together to create a culture of collaboration, to deliver value fast. Without the right mindset, we may still succeed, but will still generate a great deal of waste in the process, and reach our goals more slowly.

In extreme cases (and I have seen such cases), the entire organization gets stuck due to a lack of collaboration, to the point where they are not able to deliver.

So what is DevOps?

"DevOps means that there are no walls, no gates, no transitions, and no ceremony between Development and Operations. They are seamlessly integrated (when viewed from ’above‘) into a single, value delivering, IT entity." 
“(DevOps is)…an integrated approach to software delivery that include process, tools, technology, resources.”

DevOps includes rapid collaborative development without hassles, continuous testing, continuous deployment and continuous monitoring, and it can't work without a proper mindset in place, one that aims to allow everyone to collaborate to deliver value faster.

It cannot work without E2E organizational support to make it happen. This means that DevOps is not only about Dev to Ops; it involves the entire organization’s culture and functions: HR, Sales, Marketing and more.
This is a huge challenge, but it is doable.

 Part 2: What is Holistic #DevOps ?

Saturday, September 23, 2017

#Agile & #DevOps posts of the month - Sep 2017

Many people wants to read quality and good agile or DevOps related content on the web. We have compiled for you some of what we think are good reading Agile and DevOps posts of this month. 

Wednesday, September 20, 2017

Agile and Production Support Best Practices

"In an ideal world, a Scrum team should be dedicated and exposed as little as possible to external disturbances. But in most cases, teams must focus on developing new software and support earlier versions of the software application in production". So what is a development team charged with application support to do? 

Saturday, September 16, 2017

The new role of HR in the agile organization

"The impact of corporate Human Resources (HR), on Agile adoptions  are often overlooked. In fact, Agile practitioners often bypass HR in their zeal to quickly change the way they work and the related people processes.R to a hole new level...There is a misconception that Agile exclusively falls under the IT domain; overlooking the fact that the core of Agile is about the people and culture – the sweet spots of the HR profession."

10 #Scrum Master Interview Questionnaires to choose from

Such as "Explain Agile in 30 seconds."

Thursday, September 14, 2017

The different roles of the spotify model.

Spotify Chapter lead vs. tribe lead vs. functional manager vs. Team lead vs. Functional manager etc.

Sunday, September 10, 2017

What the role of a #DevOps coach? Part 2 (4) : What is Holistic #DevOps ?

By : Liat Palace  (Director, Delivery Technology Office Agile/DevOps Coaching Team Lead – Amdocs)  & Shirly Ronen Harel (Co-Founder & Agile / DevOps Coach -WeChange)

“DevOps does not just mean the technical practices and tools to put your code into production with confidence. It is much more than that. It is an overall approach where the entire organization must acknowledge the existence of DevOps. Starting from sales and marketing, DevOps must be an integral part of their processes to be included in every project. It must be taken seriously. Eventually, when the project is passed on to the next party taking responsibility of the project, it is essential to have best DevOps practices in place.”

DevOps practices exist throughout the lifecycle of a product, from sales to support.  They don’t focus on one person or on a small part of the organization; instead they address the entire production line, providing end to end value stream cultural change. When an organization adopts DevOps, this affects different parts of the organization. It is a culture, a mindset and practices that should be present across the board. It means removing barriers and building a collaborative culture that affects much more than just Dev to Ops.
Adopting DevOps is hard. It requires management support, a company-wide mindset change, and of course coaching.
If DevOps is a culture of collaboration, then we cannot limit the close collaboration and continuous feedback to development, testing and operations. We also need to include accounting, marketing, sales and more in the loop; otherwise the organization will sell and market deliverables that the Delivery group will not be able to deliver. This would leave us in the same place we were when Agile was implemented on development only, while testing and operation were out of the loop. This is good but limited, and we no longer want any limitations.

If we want to achieve Faster, Cheaper, and Better, this requires the entire production line to be involved. As an example, the Sales department cannot enter into a ‘silo’ contract with a customer, while Delivery delivers a small chunk of working software each sprint. All parties in the organization must be aligned with the same mindset.

Defining job titles such as “DevOps engineer” and “Director of DevOps”, and creating DevOps training and certification programs, are not sufficient. DevOps is a culture; it’s not silos of specific people developing tools or collaborating among themselves. It means that everyone in the organization is part of a single approach call DevOps. Everyone is expected to act according to the principles and values of the DevOps approach. However, a DevOps coach is a sufficient term, it's a leading role in transforming an organization into a DevOps organization, using a holistic approach, addressing system thinking, and focusing on the end result.

Monday, September 4, 2017

Matrix Resource Management and #Agile

As matrix management encroaches upon Agile management the philosophical view points on resource allocation are contrary to each other. 

Sunday, September 3, 2017

The #agilefamily team - Stories from 2017

How do some families and individuals incorporating agile methodologies into modern family life in 2017?

What is it like to work ( #agile ) with Ukraine?

Tuesday, August 29, 2017

Breaking Paradigms- "Traditional management" doesn’t work any more.

The principal cause of the erosion in returns is the shift in power in the marketplace from seller to buyer. As a result of globalization and the Internet, customers and clients have more options and instant access to reliable information about those options.  Hence firms that revolve around the boss with a dynamic of control and a principal goal of ever greater efficiency have been finding it more and more difficult to make money.

Monday, August 28, 2017

#DevOps Infographics

Wednesday, August 23, 2017

What's the role of the feature lead in agile projects?

"They are the team members whose job it is to be the customer proxy for a feature, defining what is important to the customer and owning implementation end-to-end. They are assigned these roles because of the number of features that exist in a typical product. Being a feature lead takes both attention to detail and orchestration capabilities in order for the feature to be well defined, implemented, and delivered. " What’s their role details ?

Tuesday, August 22, 2017

The Holistic approach of #DevOps - It's for the Entire (!) organization.

"Devops does not just mean the technical practices and tools to put your code into production with confidence. It is much more than that. It is an overall approach where the entire organization must acknowledge the existence of devops. Starting from sales and marketing, devops must be an integral part of their processes to be included in every project. It must be taken seriously. Eventually, when the project is passed on to the next party taking responsibility of the project, it is essential to have best devops practices in place. "

Friday, August 18, 2017

Working #Agile with China

The challenges of adopting agile software development methods vary from one context to another. Asian cultural backgrounds may impact agile practices adoption.

Friday, July 28, 2017

How to adapt to the Israeli working culture?

Israelies hard to work with. More than other nations? Depends on how you look at it.

Wednesday, July 26, 2017

#DevOps mind-maps

Saturday, July 22, 2017

Implementing #Holacracy - How?

Holacracy completely replaces the conventional management hierarchy with a tested, customizable self-management practice that empowers people throughout an organization to make meaningful decisions and drive change.

Thursday, July 20, 2017

11 rules of thumb to help you measure the success of your Agile/DevOps coach

By : Liat Palace  (Director, Delivery Technology Office Agile/DevOps Coaching Team Lead - Amdocs)  & Shirly Ronen Harel (Co-Founder & Agile / DevOps Coach -WeChange)

While many people use Agile and DevOps coaching services, few of us really know how to measure the success or failure of the coaching process.

What will help determine whether the coaching was a success or failure?

The working environment is complex and includes many parameters that can influence the success of every implementation; in this context, how can we identify the coaching achievements? 

The most important thing is to determine as early as possible whether the coaching is effective, in order to ensure that the efforts are productive.

Here are 11 rules of thumb to help you validate the coaching effectiveness.

1.    Clear Expectations & Definition of Success

The first and most important thing a good coach will do is understand his customer’s/ (Or  The project sponsor in some other cases)  perception of success. This means that the coach will ask the project sponsor what he/she considers a success.  "Once we’re done here, or have made progress, what will the change look like?” What will the sponsor consider success? Is it a better delivery rate? Solving communication problems? Successfully addressing quality issues? Better handling of unexpected issues? Is the success story a realistic one? Does the sponsor expect magic? Does he expect aggressive demands on the team? And so on…
The definition of success will affect the implementation vision and goals, along with the ability to achieve success and impact. It will also impact the feedback loops, the people involved, and the implementation journey.

Clearly envisioning success at the beginning will make it easier to identify signs of success and share them.
Here as well, continuous feedback regarding the customer perception of success is required. Things change during the Agile journey, and so does our understanding of success.
Therefore, when asking “are we there yet?”, identifying “there” is key, along with continuously obtaining feedback on the journey.

2.    "Language" changes - A wider use of Agile jargon

We start noticing a wider use of Agile jargon, and not in a cynical or offensive way. The use of "DOD", "READY", and "working software" becomes more widespread and acceptable as organizational jargon.
Furthermore, the jargon is used as a symbol and tool of the mutual understanding of the actions to be taken. Behind any term there is a wider understanding of what should be done, which is probably different from the "book" or the use of the same method in other organizations.
The use of the terms fits the organization mindset and the process established, and results in fewer misconceptions regarding what, for example, "daily" means, what grooming is for, and so on.

3.    “Proud Parent" or “Mr. Miagi” moments – Moments in which the coached team makes the coach proud.

An article in the illustrated Agile blog (8 Ways to Measure Your Impact as an Agile Coach), describes a phenomenon familiar to every coach who delivers value. These are the proud moments when your coached team does something to make you feel proud. These “moments” should occur at least once a week. Keep a log of how often they occur for you. As an example, here is a recent page from my journal, when I captured the experience described above. The impact of an Agile coach should FIRST be measured by the growth in confidence of the coaching environment, and how soon they are able to “stand on their own.”

4.    Problem solving - The coach as the Agile "Help Desk"

We start noticing that people seek the coach to help them solve problems, and actively seek his advice in the area of Agile implementation.

This means that the process and the way we work to enable better, faster and higher quality delivery is sufficiently important for us to seek guidance for improvement, and the person to ask is the coach.

A more advanced sign that we are gaining value from the Agile coaching is that not only the coach serves as the source of advice, but also other people who are not managers can give good advice and are perceived as sources of Agile knowledge.

5.    Better delivery

The most obvious sign of a successful Agile implementation is a better delivery. Now, what does this mean? Does it mean 100% sprint delivery? Does it mean double or triple the cycle time of user stories? … Nope. It means small improvement steps in team or group delivery.
Real improvement will also include a better understanding and implementation of the DONE concept, which includes quality activities and other lifecycle activities. It means that the team has improved in its ability to balance multi-disciplinary activities. It means that improving tools which affect speed and quality becomes an effort that is sufficiently important to undertake.  It generally also means that communication, problems solving, and waste reduction activities are improving as well.

One of the best indications of good deliveries is a decrease in Escaping bugs. Escaping bugs are customer reported bugs. When they decrease, it means that we have achieved our desired outcome without sacrificing quality.

But this is not the only sign, and probably not the first one. Sometimes we may initially see a period of degradation in delivery, since the team is learning new skills that demand attention and effort, at the expense of other activities.

6.    The process itself is a topic of conversation

We notice that just as technical, testing or HR issues are part of the day to day concerns, so is the process. The process becomes part of daily project discussions, management discussions, and team discussions. Improving the way, we work is an ongoing, almost natural issue that is communicated by employees and managers across the organization and throughout the different activities.

7.     Unofficial frequent communication

While at the beginning of the Agile implementation the majority of communication and updates are done during the official meetings, as we progress with the Agile/DevOps implementation, we expect to see much more direct and unofficial communication. People understand that they do not need to wait for an official meeting in order to communicate or solve a problem, and they can approach each other unofficially. Once they are connected to the same vision and understand the project priorities, this creates communication and collaboration that will shorten the problem resolution time.

8.    Continuous improvements

Teams that have successfully integrated this mindset are constantly reflecting on what is going on and trying to improve.
You see people standing by the coffee machine, saying things like “we must take this to the next retrospective and investigate what happened here”.
Every process/behavior should be reevaluated all the time, as the conditions are always changing, which means that we are never Done!
This is a live process of changing, evolving and responding; inspecting and adapting and learning from failures.
We need to expect improvements at least once a month, both at the team and project level.

9.    TTM of new ideas

New ideas are generated faster, tested faster with experimentation and accepted and implemented faster. This is a good indication of a continuous improvement mindset that allows openness of communication and ideas. We notice that problems are discussed and action items are assigned and actually executed. Small steps are applied instead of big project solutions.

10.   Culture 

High performance organizations differ from low performance organizations in the area of culture. (State of DevOps report 2017)
As the DevOps/ Agile implementation matures, it should be reflected in the organization DNA:
-          Continuous experimentation
-          Treating failure as a learning opportunity
-          Promoting learning
-          Empowerment
-          Employee satisfaction

This is much more than “doing” Agile/DevOps; it is “being” Agile/DevOps.

11.  Employee engagement

This should increase, with employees feeling that they are challenged more, learn more, and collaborate more.

How can we make sure that we continue to succeed after coaching phase out?

We usually see implementations fail when one of the conditions changes and the team does not know how to adapt the processes to the new state.

Growing self-repair mechanisms - the ability to change processes, understand the impact and do better all the time - are key differentiators.
Too many times we have seen implementation kits that list all the items to be deployed, but totally ignore the project goals and definition of success.

Let’s be clear: Delivery success should come first and the Agile/DevOps implementation should work towards achieving it, changing and being tailored to suit the project needs.

Evaluate the work that was done; see what was accomplished so far and what was not. Learn from our journey, and from those of others as well.
Prioritize your goals, provide your coach with feedback and update your targets accordingly.
With these rules of thumb, regardless of where you currently stand on the Agile or DevOps path, you are poised to embark on a path to success.

Monday, July 17, 2017

#Agile Vs. #DevOps - How they are different?

DevOps and Agile are not exactly the same thing. But they are complementary to each other. 
In addition to this, the broad use of DevOps in Agile methodology has made it a more compelling approach for IT commercials. In this context, it is important to know that Agile is not DevOps, and DevOps is not Agile. It is difficult to achieve success in DevOps, if Agile practices are not followed. While Agile can make sense independent of DevOps, it can be more complete when accompanied by DevOps practices.Here are the emerging Agile and DevOps Trends.

Friday, July 14, 2017

How to manage the the Product funnel ?

The iconic product development funnel has worked well because it implies that product development is a refinement process that takes us from the earliest stages of a project—with a lot of fuzzy ideas and fuzzy thinking—to the final stage of new product launch.

Thursday, July 13, 2017

#DesignThinking Vs. #LeanStartup - Which to use, and when

Design thinking and lean startup. Both approaches involve  customers, potential users, or other stakeholders into their development process. Although there are significant differences in both  strategies,  there  are also  several  similarities  in  methodology and  process  design . Here they are : 

Sunday, July 9, 2017

What comes after agile?

We can assume that whatever comes in the future will most likely answer the need for fast cycle and will probably keep this cycle in place, only looping faster. What will it be?

Friday, July 7, 2017

“Show me the money!” - What's The ROI of DevOps?

"Fortunately there is plenty of evidence to show enterprise executives exactly where to look when trying to determine the ROI of DevOps." DevOps is commonly introduced into organizations for some well-understood, and usually highly justified, reasons. DevOps speeds the overall pace of the software development and release cycle, improves the quality of deliverables, and helps to resolve problems more quickly. But all of these intangibles should, and do, flow down to the bottom line. Which means that any well-designed program should include a healthy perspective on ROI.

Wednesday, June 28, 2017

Agile Games And Exercises