New Paper on Matrix Equivalence

Just finished this recently. Glad I was able to arrive at a solution that is also constructive and assumes existence of a normal form for matrices over a certain type of commutative local rings with 2-generated maximal ideal. Matrix equivalence, if solved for a class of rings, has impact on classification problems in other areas such as linear groups, finite group representations, finite-dimensional algebras and more.

The paper is available at the following locations:

OSF Website: Matrix Equivalence and Reduction to Normal Form over Commutative Local Rings with 2-generated Maximal Ideal.

Academia.edu: Matrix Equivalence and Reduction to Normal Form over Commutative Local Rings with 2-generated Maximal Ideal.

ResearchGate: Matrix Equivalence and Reduction to Normal Form over Commutative Local Rings with 2-generated Maximal Ideal. 


In both cases the full text is accessible.

Welcome to Org Mindset (Alex Yakyma)

by Alex Yakyma.

In January 2017 I launched a new company, Org Mindset (http://orgmindset.com). The mission behind Org Mindset is to help organizations grow the right mindset and culture for organizational learning, innovation and agility.



If you are an organizational change agent or a leader who is looking to take the organization to the next level, you may be interested in taking one of our Org Mindset Lean-Agile Enterprise Coach classes in the US.

Here you can find more information about the course: http://orgmindset.com/enterprise-lean-agile-coach-course/

...and the class schedule: http://orgmindset.com/course-schedule/.

Good luck with your transformation.

New Ebook: Pacific Express

Recently, after working literally day and night, I finished a short ebook - "Pacific Express" - a novella about adopting Lean and Agile at Scale, Systems Thinking and... courage that those change agents in the field demonstrate everyday in order to succeed with the magic of software engineering at large scale.

Why magic? Well, it's not really magic, but it takes a whole different mindset to be able to break the bondage with the ways of working that were developed in the past but still prevail across the industry. It takes a whole different paradigm in thinking about software development process, as even those organizations that managed to adopt agility at the team level, have often nothing to operate with at the higher levels of the organization. But guess what - that is the level where most interesting things occur and we're about to explore it on a fictional example of an organization that grew too fast to sustain any decent level of productivity and starts stagnating in the core area of the business. This light read will guide us through the transformation processes they chose, their challenges and discoveries down that path, that may lead them to better performance in delivering value to the business.

Oh, did I say "fictional"? Although the organization and all characters are fictional, we will be witnessing facts and situations that occurred in real life, in the organizations that the author worked with in the past.

Enjoy!

Why SAFe Has Hardening



By Alex Yakyma.

We used to consider hardening effort as an extremely controversial topic. It’s been discussed multiple times in the community, never without emotions. At times the arguments can feel like full-fledged religious warfare. In SAFe, hardening is one of the three components of the HIP Sprint that is placed in the end of the PSI, and stands for Hardening, Innovation and Planning. 

The term suggests that this sprint reserves capacity for PSI planning itself and planning preparation, as well as placeholders for hackathons,  research activities for the next PSI, and, finally, the room for completing any work that was not covered during the regular sprints. Now, take a deep breath and hold your arguments for a little bit longer, as we are going on a journey that will help us understand the multiple misconceptions and misinterpretations with respect to the hardening.  If you bear with me through the rest of the article, a lot of things will become obvious and totally logical.

The most “troublesome” aspect of hardening to many is that hardening sounds overly waterfall’ish, representing an additional phase in the process covering a bunch of aspects that weren’t tackled earlier. I will surprise you with the answer to that - yes, indeed, hardening stands out as a separate timeframe that is not inherently agile. And yet, hundreds of SAFe consultants (SPCs) in the field and their numerous clients adopt hardening, a knowingly non-agile construct. Why? For a number of reasons.

First, SAFe is adopted by a number of large Fortune 500 organizations that develop both software and hardware. It may indeed be hard to do thorough testing of the navigation system on  an actual vehicle or a new air conditioning configuration system in a real building in every sprint. In this case, we fully utilize Lean Thinking and the concept of batch/lot size optimization and a balance between transaction cost (mainly reflecting different levels and aspects of system integration and testing) AND holding costs (which mostly is the growing complexity of un-validated increment of software). And in many cases, the optimum batch size for concerns like end-to-end testing on the target hardware environment turns out to be more than two weeks.

Second, somewhere in Narnia there lives a lonely agile team consisting of seven dwarfs and a Scrum Master. They develop their own product themselves. Most likely, they can move full steam ahead in a matter of two week sprints that include all aspects of software engineering. Well, the usual reality of software engineering at scale resembles more of Mordor, than Narnia. It involves tens or even hundreds of teams, millions of lines of code, and brittle product architecture that’s been around for 12 years already, because the first version was written by the company’s CEO himself. Wouldn't it be nice if they could cover all the steps in the value stream every two weeks? Yes! It would be awesome. But can they really do that at this point? Even if we deal with pure software (no hardware involved),  many aspects would absolutely disrupt sprinting. What SAFe strongly recommends is to “choose the blue pill” and get back to reality, no matter how dark and ugly it may seem. Hardening is very important, and absolutely needs to be called out explicitly, otherwise there is absolutely no chance to reduce it or even get rid of it in the future, even in the cases where removing it is feasible. Taiichi Ohno was always emphasizing the importance of clear goal setting as no improvement is possible otherwise. The goal can be even overly aggressive, according to Ohno -  that's how Toyota managed to implement such extreme practices as SMED - but it needs to be explicit and aware of the current state. That's why hardening matters. In many cases it's a temporary necessity that is absolutely critical to purposeful, continuous improvement. This perspective of hardening allows agile release trains to clearly separate definition of done (DoD) for stories on one hand and from that for the features, on the other hand. The whole matter of reducing or even fully eliminating hardening can then be explicitly interpreted as a gradual process of bridging the gap between these two DoDs.

Next, every once per PSI they have hardening activities... Well, here comes the limitations of the visual representation of knowledge and the overall desire to keep things simple as much as possible. Not always at zero cost. We place hardening effort at the end of the PSI on the Big Picture, and the initial suggestion would be to do exactly so in the beginning. But it is not necessarily the end state. As program matures over time, its holding cost and transaction cost curves change their shape. Normally, transaction cost curve flattens (which is the evidence of improved program's efficiency in integration, testing, tech writing, UAT, etc). As a result, the optimum batch size may become smaller. In such cases, we strongly encourage programs to split the hardening effort into more than one occurrence in the PSI. So, for instance, they may have one hardening chunk as a second week of sprint three and a second week of sprint 5, in a five-sprint PSI. Quite possibly, but not necessarily, their next step after a couple of PSIs would be splitting it even further and thus basically reach the point where hardening effort gets fully distributed across every sprint in the PSI. In other words, story DoD becomes equivalent to feature DoD. Overall, it is totally logical that different aspects of hardening may take a different optimum batch size. So, for example, full system integration could and should eventually be performed in every sprint (however it can be a real stretch for most organizations in the beginning). Tech writing and releasing to production – every two sprints, for instance. Full UAT and training internal users – once per PSI.

The whole unnecessary, emotional load that is so often associated with the word “hardening” fully disappears as soon as we adopt a systems thinking view, of which Lean Thinking is a great example that we use throughout the framework. As we stop being religious about agile and look at a broader picture and a full value stream, things begin to gradually add up. Achieving continuous flow of value at scale indeed requires additional constructs, like hardening effort. It may not seem highly desirable to have one, but it reflects the reality of many organizations and gives them a solid chance of substantially improving their practices and techniques in the future. Also, as we learned, hardening comprises a whole bunch of distinct aspects, of which some may be fully embraced by agile teams as a regular sprint routine --some can be done more frequently than once per PSI, and some may still require lower frequency. We see hardening as important tool, a result of “systems thinking” rather than the final goal itself.

Agile Engineering Assessment at Scale



By Alex Yakyma. 

I had the intention of putting together a consistent assessment of such kind for quite a while. Some topics were part of other assessments, others were just assumed.  Recently though, as I finished working on DevOps article for SAFe, I have decided to finalize this assessment as well. Especially because I could then add a good fresh summary related to the deployment process. So, here it is...


The purpose is to assess program capabilities in the following key engineering/technical areas: Architecture/Design, System Integration, Acceptance Testing, NFR Testing and Deployment. 
It makes sense to use it actually in both program and team environments. Programs need to understand where they are with respect to engineering concerns. But teams actually employ the practices and keep the work flowing, so they need to carefully track where they are as well. It is also useful to look at this assessment as a set of improvement objectives and incrementally work towards accomplishing them.