Gil on 'EVERYDAY UNIT TESTING' @gil_zilberfeld

Presents practical solutions to common problems experienced by teams implementing testing on daily basis. It covers topics like unit testing tools, methodology, writing tests and maintaining them, debugging on failure, TDD (Test Driven Development), picking a testing strategy for the organizations, and much more.

Causal Loop Diagram -Understandung deeper dynamics.

Some things are better expressed with a visual model than in words alone.  Casual loop diagrams are used to create a visual relationship model as we investigate the networks and interactions of situations. Highly effective for agile coaches.

Are you Done, Done and Ready, Ready?

Prepare a story that is “ready ready” not just kind of ready, or sort of ready. Stop asking, "Are you done?" and start asking, "Are you Done, Done?"

How can I quantify and control technical debt?

Technical debt is a common problem of many teams. It affects everything they do. It disrupts plans, kills productivity, and creates defects. A major problem of Technical Debt is that it’s not obvious. Anyone can see the amount of debt on an account statement. But how can we actually recognize it? And what are the ways to handle it?

What is program management in agile development?

What is program management in agile development?  

Program managers needs to adopt a disciplined but yet flexible agile approach to be able to manage  organizational deliveries, allowing for iterative and incremental delivery of outputs and benefits. Here’s a collection of posts dealing with exactly that. Enjoy .

The Dev & Delivery Dance - Can R&d and Delivery work together?

By Tommy Quitt.  The spotlights on the dance floor are on a couple dancing passionately. Ms. Development and Mr. Delivery are finally together. But is this really a dance or a power struggle? Who leads? Who is being pulled?

DevOps: Can R&d and Delivery work together? (#3)

Guest Post by Tommy Quitt - Business Mentor at WECHANGE

My previous blog was a bit pessimistic in a way. It concentrated on the differences between R&D engineers who think in a different way from their peers in the Operations organization. They’re interested in different things and use different tools. Still, today, organizations want to streamline their end to end processes from requirements all the way to go-live in one single process that will ensure quick and smooth delivery of the system to the customer.

So what should you do if you want an organization that fights less and works better together?

Shared Goal

It is imperative to set a shared goal around the main problem you are trying to solve. For example, if the main issue you have is that systems that are installed for customers are not stable you may decide to set the goal of “delivering a stable system that will maintain 99.99% uptime”. The contribution to that goal should come from both parties: R&D should build a system that does not crash, and Delivery should help by providing the right requirements early in the process, by stabilizing the implementation, testing in the labs, monitoring etc.

It is important to emphasize that with a shared goal, no single entity will be blamed on failure. It is the responsibility of the team to make sure that the goal is met. If failure happens, try to use it as a learning opportunity to see how the cooperation can be improved.

You may choose other goals, like delivering faster with less iterations to fix issues in production, you may want to improve performance, you may want to automate testing and deployment processes and a wealth of other possible objectives that may arise.

The shared goal has to be not only well defined, but also constantly reminded to the teams, especially in time of difficulty and crisis. In fact, remembering the shared goal is a good way to bring everyone back to the discussion table instead of focusing on the differences.

Processes

Keep in mind that end-to-end R&D to Delivery processes usually are more than the combination of two distinct processes. If you want to induce a real change, you must be ready to make changes to your existing processes to reflect the new way of working.

For example, product definition processes that traditionally do not take input from operations, should now include steps where system experts will be invited to define requirements that would be implemented in the product. This would be an opportunity for them to influence performance, stability, monitoring and other operational issues. Down the road, it also means that testing these requirements would become part of the responsibility of the product Quality Assurance processes. Just imagine what a big change this could be!

You may find yourself changing the Release process. If previously it involved only compiling and packing the product you may choose to build also upgrade and rollback scripts as part of the product release. This is something that previously used to be the responsibility of operations, but with a shared goal of smooth installation may move earlier to the product release stage.

In the same way almost every process in the organization may change. Keep your mind open and flexible. Do not cling to your existing habits.

Change Implementation

Try to be agile about the way you implement the change. People usually find it difficult to cope with big changes and respond better to smaller digestible adjustments. Additionally, there is no way for you to understand and plan everything before you hit the road. So simply do what we do in an agile product development: Go for continuous change that evolves over time, and prepare to be responsive to feedback from the field while you implement the change. Do not be afraid to change your plan as you go and make sure you are transparent about your motivations and your plans.

But these are only the first ingredients. Want the whole recipe? Hang on for the next post.

How to use Scrum with Kids and Family?

Using scrum techniques with kids and families is a wonderfull and easy thing to do.

Empower your children without losing your parental authority, through a collection of practical actions. Being able to adapt your family to modern life changes and pase. The methods are effective at teaching values and respect to others, and applies to public and home schooled children alike. And most of all , its so easy and so fun.

Holacracy - A COMPLETE SYSTEM FOR SELF-ORGANIZATION

Holacracy revolutionizes how a company is structured, how decisions are made, and how power is distributed.

Better get used to seeing this word around.

Holacracy is a system of organizational governance in which authority and decision-making are distributed throughout a holarchy of self-organizing teams rather than being vested in a management hierarchy.

Why is it difficult for Delivery and Development to work together? (#2)

Guest Post by Tommy Quitt - Business Mentor at WECHANGE

By now we understand that in today’s world R&D and operations must work closer to achieve the goals of the company. Fast deployments, short iterations, quick value dictate cooperation between these two departments. (See Part #1)

Well, the main reason is that they are different. They are different in what is important for them, the tools they use and even their language.

How come two groups working in the same industry and in the same company can be so different? The first aspect is what they deal with every day.

Developers have challenges around Functionality. They must build code that isPerforming, Testable, and of course of good Quality. If they are really good they would also try to deal with Extensibility (minimum effort to use the same code again in different scenarios) and Scalability (software does not limit us to deal with infinite amount of data, users, traffic etc.). Some of other R&D challenges would be around the Release process: the effort to streamline code management, testing and packaging into a smooth working practice.

Our Delivery friends (often referred to as “operations”), have completely different thing on their minds. They're occupied with the effort to build a system or systems that meet customers or markets requirements and that can guarantee the revenue of the company. Thus, they're interested in Availability, Load management andSLAs. They try to implement proper Monitoring of the production systems and to have Diagnostic tools that would allow them, once a problem arises, to quickly identity the root cause.

If you would listen to a chat between two developers you would probably hear them discussing Code, how to Optimize memory or performance, or simply how to get one module to work with the other.

In a typical Delivery lunch you would hear stories on “how I was woken up in the middle of the night because the system was down” or how somebody managed to automate deployment or monitoring processes. They are all about standards, configuration and implementation of customer specific business processes.

Naturally, the language used is different. Developers use words like “Pointers, Sprints, Scrum, Compilation, Libraries” etc. while delivery talk about “Change management, availability, Clusters, DMZ, SNMP, Scripts” etc.

The most significant difference, to me, is about the definition of done: When do I deem something complete and finished.

Developers have a few items on their checklist: Have I implemented what I committed to in the sprint or release? Does it work? Have all of my unit tests passed? Most developers “make it work” usually on their own machine or in better cases on a “development server”. That is of course not enough for operations. To them testing must happen on multiple instances, different topologies, concurrent users and traffic, big amounts of data, complex network topologies and endlessly more scenarios that resemble real life customer situations. For the Delivery, a system is stable only when it was running for days while being stressed in all dimensions. They want to run parallel tests to make sure there is no regression of functional or non-functional aspects of the system in the newly released version. They want to make sure they can install the latest version and still be able to rollback in case problems arise post installation. In other words, when the developer thinks “it is ready”, the delivery engineer know that a long road lies ahead before this can go into production.

So can these two different worlds work together? Of course they can. Hold on for the next post…

Tommy Quitt helps software organizations' managers make the leap forward by implementing the changes and improvements they always wanted to happen.

The Dev & Delivery Dance (part 1)

Guest Post by Tommy Quitt - Business Mentor at WECHANGE

The spotlights on the dance floor are on a couple dancing passionately. Ms. Development and Mr. Delivery are finally together. But is this really a dance or a power struggle? Who leads? Who is being pulled?

In the upcoming few posts I will be discussing the challenges that delivery organizations face today and how they can solve some of these issues by adopting principles and agile methodologies.

Delivery functions developed in organizations that needed some level of customizations or even simply installation and integration of their products to final customers. The delivery group would take the finished product and using either internal or external (we will explain that later) customization options made sure the system will provide value to the customer and more importantly, be stable and resilient.

If we do not talk – we have done a great job…

In the organizations I used to work for, the level of “independence” of the delivery organization used to be the measure for the completeness and the quality of the code delivered by the R&D organization. If my code was well designed, with the right customization options (like configuration files, business rules, etc.), then a delivery engineer should not have to contact me with questions or worse, with requests for code changes that she needs for a successful on-premise installation. In other words, minimal interaction between delivery and R&D are the indication of a well architected system.

But see what happens in reality: The delivery team struggles to install and integrate the system and often they are frustrated because real life, production system requirements like performance or configurability were not considered by the R&D.

Now, that was very logical. We had two completely different skills here: on one hand, the engineers, “scientists” that are busy with writing the most general, best performing, bugless code and on the other hand the guys “on the ground”, “the infantry” if you will, that knows best the customer and should bridge between the product and the specific customer requirements and integration. The bridge between these two sometimes distant universes was the implementation (carried out usually by non-compiled code or interpreted code or scripts, parameters, etc.).

The “Solution”?

So imagine the CEO having a serious talk with the R&D Manager: “I expect you to care not only about functional requirements, but also think about nonfunctional requirements like performance, stability, load balancing, security etc. I do not have the luxury of investing weeks of works after your release in installation and integration. I need the software deployed as fast as possible.”

Then the CEO turns to the delivery manager: “At the same time I need my professional services team to work very closely with the R&D team for the same reasons – I need a flow of releases deployed to production contradictory to the previous long cycles of release->customization->testing->deployment  we used to have earlier.”

So the next steps seem very logical: let’s bring these two together or even put them in the same team. That is what often happens: management takes a decision to “implement DevOps” by forcing R&D and delivery to work together for the same goal, “deploy a release every week”, for example, and then finds out that it does not work.

The reasons for that are diverse and routed deep in the nature of these two professions. But let’s leave this for our next post.

What type of relationship have you witnessed between Delivery and Development? Share with us in the comments below.

Tommy Quitt helps software organizations' managers make the leap forward by implementing the changes and improvements they always wanted to happen.

Why Lean often Doesn't Work?

Working UX in Scrum

With the rise of agile and lean approaches across our industry, UX professionals are likely  to find themselves supporting agile projects. Yet, many seem stymied by the challenge of effectively integrating UX within an agile development framework. here's how we can easily integrate into scrum and overcome this challenge.